Raspberry Pi Zero connection

lawrie 2018-03-17 08:33:18 UTC #1

When the mystorm device was first announced, its connection to a Raspberry Pi Zero via the header was a prominent feature. I haven't seen much about this on the forum or elsewhere lately.

I was wondering it anyone is actively using the Raspberry Pi header.

I am doing development from a Raspberry Pi but using a USB cable for the connection, which is the documented way in the getting started guide.

I have been looking at robotic applications using my Blackice II, and have a simple one with encoder motors and an hc-sr04 ultrasonic sensor. Adding a Pi Zero might be a good way of providing remote control and monitoring over Wifi or Bluetooth or Bluetooth Low Energy.

One issue is what do I do about the jumper that switches between DFU and Iceboot modes if I am using the Raspberry Pi header?

A slider switch for switching between DFU and Iceboot modes might be a better solution in future versions of Blackice. Or a separate jumper header.

It would be useful to have instructions on how to set up the serial connection to a Raspberry Pi using the header as the use of serial ports changed considerably on the Raspberry Pi when the Pi3 was released, so it is not trivial.

I am also not sure about the decision to use a male header for the Raspberry Pi connection. Although you can solder either a male or female connector to a Raspberry Pi Zero, male headers are more common as they work with hats.

Which brings me to the issue of whether the Raspberry Pi header is designed for connection to a Raspberry Pi or to allow use of Raspberry Pi hats, or both. Has anyone used it for a Raspberry Pi hats? Is it possible to read the EEPROM of Raspberry Pi hats from the STM32? As the software for Pi hats is usually linux based it might be difficult to access a lot of them.

I have some Raspberry Pi pHats such as the Redbear IoT pHat, which could be another way to add Wifi and Bluetooth to the mystorm device, but looking at it, the pins that it uses are not available on the mystorm header or are used for other purposes. This might be an issue for a lot of pHats.

Folknology 2018-03-17 09:46:25 UTC #2

Hi Lawrie, yes on initial myStorm boards we used the RaspberryPi to actually program the Ice40 and use the uart, more recently however folks just tend to use the USB as it is easy and documented.

In terms of connections the uart is connected to the rx/tx ports of the RaspberryPi and also the SPI connection from the Ice40 can be muxed onto the Rpi SPI pins but you would need to activate that in the Iceboot firmware. You could then use these pins to program the Ice40 along with the reset and done pins which are also connected to Rpi header. What is more you could even then create Verilog that used SPI to communicate with the Rpi if you so wished. Also to get over the DFU/Boot issue you would need to have the Rpi pull down the GPIO pin attached to the boot signal. Basically everything can be done from the Rpi with just a small change in the firmware for the mux setting.

Not sure anyone has tried using hats, that was not the original purpose, it's mostly there to connect to a RaspberryPi normally via a cropped IDC cable (loose the upper 14 connections on a 40 to 26 IDC). It is not possible to read the EEPROM on a hat as those pins are not present, we effectively have the old 26 pin header..
There is also no 3v3 supply to the Rpi header so this may be a big issue for those apps.

lawrie 2018-03-17 11:58:02 UTC #3

Presumably after pulling down the boot pin, you would need to reset the STM32 to use Iceboot.

The i2c pins (SDA and SCL) also seem to be on the header, so i2c would be another way to talk to the STM32.

I do have some Raspberry Pi hats (for robotics) that only use i2c so there is a chance that they would work and could be driven fro the STM32. However that lack of the 3.3v connection is probably a stopper. Is there a reason why that was not connected?

Folknology 2018-03-17 12:52:11 UTC #4

Yes the STM32 can be reset from the Rpi using !reset signal, yes I2C is another way to communicate if required (lower bandwidth than SPI).

No 3v3 because that would fight with the Rpi 3v3, you could tap the 3v3 from the Arduino Digital 3 or a pmod?

lawrie 2018-03-17 13:40:57 UTC #5

Can the Blackice be powered from the 5V on the Rpi header?

I ask because I have just received a (very late) Kickstarter device called the Pijuice which provides battery power to the Raspberry Pi. It looks as if it would fit nicely on top of the Blackice device and provide power for mobile applications. It only uses the i2c pins and the hat pins, which won't be connected. If it works, you could even get Iceboot to detect the power-down signal that it sends over i2c. It has a female Rpi connector below and a male connector above, so there is a place to put the boot jumper. It would do nicely for the Blackice powered robot I am building.

Folknology 2018-03-17 15:55:20 UTC #6

Yes it can, it has diodes to enable either USB (vbus) or Rpi sourcing for 5v

lawrie 2018-03-20 22:10:25 UTC #7

I have been experimenting with using the RPi header to connect to a Raspberry Pi. It powers up OK and I can set BOOT low and then do a reset to make the Blackice go from DFU to Iceboot mode. (I was a bit confused at first by the two different reset pins on the header).

I then realised that dfu-util does not work via the RPi connector - it needs USB1.

I then realised that the RPi uart is equivalent to USB2, and so can't be used for transferring bitstreams to the STM32 with the current version of Iceboot.

So it seems what you can do via the the RPi connector is rather limited without changing Iceboot and even with changes, not being able to use dfu-util will limit what can be done.

I am experimenting with i2c connections over the Rpi connector. Different addresses could do different things. So for example, I could send scan codes from a RPi USB keyboard via i2c to the STM32. which could then emulate a PS/2 keyboard using shared pins with the Ice40. A different i2c address could emulate a PS/2 mouse. Other addresses could be end through to the Ice40, e.g for camera data.

Folknology 2018-03-21 08:38:28 UTC #8

There is actually quite a lot you can do in addition what can be done over USB (Don't forget you still have USB on the Raspberry Pi)

1) You can change iceboot to re-enable the RPi uart, although usb is often faster it also allows the FPGA to use UART on those pins. Likewise you can still use dfu-util over USB from Rpi.

2) Again with minor changes to iceboot you can have it take a back seat, leaving responsibility of ice40 programming directly to Rpi (see Icestorm for an example) along with mux control.

3) You can also reprogram and debug the STM32 using the STLINK pins from the Rpi

4) You can also communicate at quite high speed directly with the Ice40 over SPI (with 1 and 2) assuming you include some basic SPI slave Verilog.

5) You can also use I2c as you mention, so lots of options really.

6) The reason for the arduino port in addition to Ice40 Programming in that environment has been designed to ease into such applications that go beyond iceboot..

It really depends how far you want to go and how much work you are willing to put into a given project.

lawrie 2018-03-21 09:43:27 UTC #9

Are the STLINK pins SWCLK, SWDIO and RESET (with the bar above it, i.e. COMS pin 13)?

If the STM32 is left in DFU mode does Iceboot have to be involved at all? I am unclear how the control of the MUX works. If the Rpi is using SPI to configure the Ice40, then Iceboot does not really serve any purpose. In some scenarios, you would want a different program on the STM32,

What did you mean by "see Icestorm for an example"? Do you mean there is relevant code in the icestorm github project?

I have been experimenting with applications that use the Arduino headers, mainly using Grove sensors. I tried reading analog sensors and sending the results by SPI to the Ice40, and I am trying reading i2c sensors. Both successfully.

I tried i2c over the Rpi header with only partial success. I can send data from the Rpi to the STM32, but all return data comes back as zero. I don't think it is my program as I have copied working programs and put in a lot of debugging. I am using python on the Rpi and the Arduino Wire library on the STM32. I suspect it is a problem with pull-up resistors, as that seems to be the most common problem with i2c.

What does RESET without the bar (Pin 18 on the COMS header) do?

Folknology 2018-03-21 10:27:41 UTC #10

Yes

This is theoretically possible in dfu mode (I assume the shared pins are hi-Z), although I haven't personally tried, you need to use the 'S' mux select to switch spi pins to the Rpi and 'OE' Output enable to activate them, both available on the Rpi header. For clues look at the iceboot firmware which sets the mux the opposite way enabling Leds instead, effectively you need 'S' to be inverse of this routing spi to Rpi header instead.

IceStorm has an application called iceprog, more specifically a raspberry pi version (Not FTDI), although the Rpi pins used are different, it could be used for clues. Again if you look at what iceboot does to program the ice40 you could do the same with Rpi (as is done iniceprog Rpi version),Iceprog however does quite a bit more than just that.

It resets the Ice40 which you need to do when programming it

BTW I dug out the link to clifford wolfs icoprog

lawrie 2018-03-21 12:06:58 UTC #11

Thanks for the detailed answers to all these questions. I am sure you answered some of them above and elsewhere on the forum, but I am groping my way to an understanding of all this. I think I now understand all the pins on the Rpi and Arduino headers.

This looks like a simple RPi version of iceprog that would be a good starting point - https://github.com/cliffordwolf/icotools/blob/master/examples/icezero/icezprog.c

Folknology 2018-03-21 12:12:27 UTC #12

To be honest it is complicated to use all 3 layers of the stack Rpi-STM32-Ice40 and not for the faint-hearted, things can easily go wrong at any level, Verilog alone is hard enough!

lawrie 2018-03-23 08:40:35 UTC #13

I was watching these videos on the icoboard:

https://opentechlab.org.uk/videos:013:notes

If I get a version of iceprog working, using SPI via the RPI header, then I should be able to do the things in the second video (at about 13 miuntes), such as sending videos and camera feeds to the Ice40.

I have also been following what @TomV has been doing with the ST link and blue pill board to use OpenOCD working with Blackice. If he gets the ST link working directly with Blackice, I should be able to do the same thing over the Rpi header from a Raspberry Pi.

lawrie 2018-03-24 20:34:51 UTC #14

I am making some progress using the RPi header for various things.

I wrote an iceboot replacement using the Arduino package to communicate with the RPi over the uart, so that I can control the mux and other things just using the RPi header.

After a lot of problems I have got configuring the Ice40 over the uart (via the STM32) working. I found a bug or two in the Arduino FPGAConfigure code so I will probably fork the arduino-mystorm repository and apply some fixes.

I also have sending data over SPI from the Raspberry Pi to the Ice40 via the mux working. This was tricky as there are several ways of using SPI on the RPi and most don't work that well, because, for example, they use the wrong mode and do not allow you to change it. The code from the icoboard's icezprog was not that useful as it was writing to flash memory not directly to the Ice40. Also it was bit-banging which seems unnecessary for us, as we are using the hardware pins on the RPi header. But even after a lot of changes it did not work, possibly because it was using the wrong SPI mode. I finally used the bcm2835 library which lets you configure lots of things including the mode, and that now works using SPI mode 3.

However, I have not been able configure the Ice40 over the SPI. The first problem is that the reset into slave configuration mode does not seem to work. It never unsets DONE. I did have the pin numbers wrong at one time due to the multiple different RPi pin numbering schemes. But I am pretty sure I have them right now.

To get round that I tried sending a uart command to my iceboot replacement to tell the STM32 to do the reset. That gets further, but DONE is not getting set at the end, so there must be something wrong with the data being sent. I am still investigating this.

So of the various ways to communicate over the RPi header, uart works but is a bit slow, SPI works but not yet for configuring the Ice40, i2c works but only in one direction, and I haven't tried the STLink pins yet.

One nice thing about using the RPi header is that it gives me software control over the BOOT and !RST pins, so I don't have to mess about with the jumper when switching between DFU and Iceboot modes.

TomV 2018-03-24 23:57:20 UTC #15

One nice thing about using the RPi header is that it gives me software control over the BOOT and !RST pins, so I don't have to mess about with the jumper when switching between DFU and Iceboot modes.

I now have another way around this: openocd has a “flash” command, which works just fine to reflash the STM32. That’s another thing that the BlackMagic hen server doesn’t support, so I’m completely back to using STLink.

Tom

lawrie 2018-03-25 07:37:34 UTC #16

That wouldn't currently work for me as I am using the Arduino IDE to program the STM32, and until someone changes it to use STLink, it requires DFU mode.

(I wouldn't use the Arduino IDE to do serious firmware development, but for experimentation it is very useful. But as running it on the Raspberry Pi, is not that practical, I still have to move the Blackice between machines or mess around with the jumper).

lawrie 2018-03-25 09:07:20 UTC #17

Here is my test program to reset the Ice40 into slave configuration mode using the Raspberry Pi header. Unless anyone can see a problem with this, it appears that the reset cannot be done using the RPi header. Note that pin numbering is the wiringPi convention. I have tried playing with timings etc. but to no effect.

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <unistd.h>
#include <wiringPi.h>

#define CFG_SS   10
#define CFG_RST  5
#define CFG_DONE 6
#define CFG_S    1
#define CFG_OE   3

int main(int argc, char **argv)
{

        wiringPiSetup(); // Uses wiringPi numbering

        pinMode(CFG_RST,  OUTPUT);
        pinMode(CFG_DONE, INPUT);
        pinMode(CFG_S,    OUTPUT);
        pinMode(CFG_OE,   OUTPUT);
        pinMode(CFG_SS,   OUTPUT);

        printf("DONE is %d\n", digitalRead(CFG_DONE));
        fflush(stdout);

        // Enable the mux and select the Rpi header
        digitalWrite(CFG_S,   HIGH);
        digitalWrite(CFG_OE,  LOW);

        // Reset the Ice40
        digitalWrite(CFG_RST, LOW);
        digitalWrite(CFG_SS, LOW);
        usleep(1000);

        digitalWrite(CFG_RST, HIGH);

        // wait for DONE to go low
        for (int i = 100; digitalRead(CFG_DONE) == HIGH; i--) {
                if (i == 0) {
                        printf("Config: DONE took too long\n");
                        break;
                }
        }

        usleep(2000);

        printf("DONE is %d\n", digitalRead(CFG_DONE));
        fflush(stdout);

}

Typical output is:

DONE is 1
Config: DONE took too long
DONE is 1

Folknology 2018-03-25 09:42:48 UTC #18

Well down Lawrie great work so far, a couple of ideas that might help:

First thing to check is that the signals are actually doing what you are asking them to, if you have a scope or logic analyser that could help here. Make sure that the STM32 isn't interfering with the reset signal for example, it needs to hi-Z that GPIO pin.

Secondly I don't know much about the wiring pi library but you might want to try an alternative to :
// wait for DONE to go low for (int i = 100; digitalRead(CFG_DONE) == HIGH; i--) { if (i == 0) { printf("Config: DONE took too long\n"); break; } }

It might get optimised by the compiler so that timeout isn't achieved perhaps use a usleep instead.

lawrie 2018-03-25 12:26:11 UTC #19

Thanks for that. Setting pinMode(..., INPUT) on the STM32 for the RST and SS pins fixed the problem. I will now have another go at doing the configuration over SPI. I already have it working at 115200 over the uart.

lawrie 2018-03-25 13:10:56 UTC #20

I now have configuration over SPI working. It is very fast.