Unreliable SPI read from RaspberryPI [solved]


#1

Hi there,

i connected my tinifpgaa1 (after flashing a led example) to my raspberrypi via spi, and i put together a quick & dirty C program to read some FPGA registers: https://pastebin.com/bEskWDLD

This same program works reliably well reading these registers from a bugblat pif2 lattice machxo2 raspberry hat, but fails intermittently with the tinyfpga:

$ ./test-spi /dev/spidev0.0
IDCODE_PUB: 0x002e010f
LSC_READ_STATUS: 0x00080001
status: Done=0, CfgEna=0, Busy=0, Fail=0, FlashCheck=No Error
USERCODE: 0x00000000
LSC_READ_FEATURE: 0x00000000ffffffff
LSC_READ_FEABITS: 0xffff0000
LSC_READ_OTP: 0xff000000
UIDCODE_PUB: 0x0040492e28427fff

$ ./test-spi /dev/spidev0.0
IDCODE_PUB: 0x012b8043
LSC_READ_STATUS: 0x00080100
status: Done=1, CfgEna=0, Busy=0, Fail=0, FlashCheck=No Error
USERCODE: 0x00000000
LSC_READ_FEATURE: 0x00000000ffffffff
LSC_READ_FEABITS: 0xffff0000
LSC_READ_OTP: 0xff000000
UIDCODE_PUB: 0x004433337954f26b

$ ./test-spi /dev/spidev0.0
IDCODE_PUB: 0x0018007f
LSC_READ_STATUS: 0x00000003
status: Done=0, CfgEna=0, Busy=0, Fail=0, FlashCheck=No Error
USERCODE: 0x00000000
LSC_READ_FEATURE: 0x00000000ffffffff
LSC_READ_FEABITS: 0xffff0000
LSC_READ_OTP: 0xff000000
UIDCODE_PUB: 0x0000992e28e15fff

As you can see the second read was somehow successful since the reported IDCODE_PUB value is correct.

Speed (500khz), bits and spi mode are correct, so what else might be? Flaky cabling? (I’m about to rewire it but i doubt it), anything else that i’m overlooking?
And has anyone connected a tinyfpga to any linux board and read the FPGA registers through any of the hardened IP blocks? (spi or i2c)

The intermittent problem smells a lot like a speed / wires issue, but i don’t know, if you have any other idea, i’m all ears.


#2

My first instinct would be to check the wiring. Make sure you have a good ground connection between the two boards and the SPI wires aren’t too long. Double-check any connectors and solder joints. Can you post a picture of your setup?


#3

After faffing around with the wires, now it appears to be working reliably and indeed, it was the ground wire: how did you know? Awesome! :slight_smile:


#4

Glad you got it working! I may have to pick your brains in future :smile:
(I was momentarily confused by the mention of Raspberry Pi since I’ve got unread stuff on the Pi forums too. FPGA comes first, though, of course!)
I’ve done some Pi programming of its I2C (to talk to a PIC I was also programming) but not done anything with SPI yet (for no particular reason).


#5

Actually i’m still struggling a lot with Raspi / SPI / Machxo2, but i’ll gladly help if i know the answer…


#6

Luke, do you happen to know what’s the max speed i can drive the SPI of the tinya1 / tiny b1 boards?

I’m writing a driver for the FPGA subsystem of the Linux kernel[1], and i while it works fine on the pif2 bugblat, i’m constantly hitting refresh errors on tiny boards - i’ve even lowerdd the SPI bus down to 100khz, still no dice.

Now userspace has no problem reading the registers of the machxo2, so cabling, ground etc should be good but i can’t find any reason why my driver works well on a machxo2 7000HC while it fails on a 256HC part.

1: https://github.com/piso77/linux/commits/rpi-4.14.y-bugblat-fpga-test


#7

That’s strange…100khz should really be no problem at all. Can you take some pictures of your setup? Where are you getting 3.3v for the TinyFPGA board from?


#8

Vcc and ground are connected to the raspberry 3.3v and gnd tracks - i took some pics but i can’t find any option o attach them to this post.


#9

Ok, according to this:

https://pinout.xyz/pinout/pin1_3v3_power

the 3.3v pin on the raspberry is able to push out ~500mA, though my other machxo2 board is using the 5v rail + tension regulator to generate the 3.3v for the machxo2 since the rpi 3.3v pin doesn’t deliver enough current - i guess i definitely need to test an independent power source now.


#10

I just updated your user level. You should be able to post a picture now. You can just drag and drop the file onto the text area.


#11

Have you been able to make any progress here?


#12

Yes, your intuition was correct: the 3.3v rail doesn’t provide enough mA to drive the machxo2 in a stable way - after switching to the 5V rail + LD33V to power the FPGA, the problem disappeared.

And i pushed the machxo2 driver upstream:

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1639557.html

though it still needs some work. After it is accepted, i’ll move to the i2c interface.


#13

Awesome, glad to hear that it’s working for you and thanks for the update!


#14

I was about to implement the i2c programming side in my linux driver, when i found another weirdness in my setup.

My tinyfpga is still wired to my raspberrypi via spi, but when i started to dismantle the breadboard (disconnect the spi side and connect the i2c bus), my led stopped to blink.
After a bit of head scratching, i put together the wires just to find out that as soon as i disconnect the SCLK pin, my ‘led bliking’ example stops to work.

Here is the verilog example i’m using at the moment: http://paste.ubuntu.com/p/jd45XRkzBS/

Do you see anything wrong in the example above?
I’m about to do some other experiments, but my feeling is that i screwed up something in the verilog code and i was wondering if anyone had any idea (never studied verilog in my life, only some vhdl unfortunately).