Hi,
I have two Shrike-fi boards. On one of them the FPGA never starts. I use the same code and the same bitstream file on both boards. One works and the other does nothing. I think the bad board has a hardware problem, but I want to ask here first in case I am doing something wrong.
I have attached shrike_fi_fpga_test.zip. It has the test scripts, the bitstreams, and two videos of the tests running on both boards. So you can watch what happens and also run the same thing yourself on your own board to check my code.
What is in the zip:
README.txt how to run everything
fpga_config_raw.py main test, sends led_blink.bin to the FPGA
spi_check.py second test, reads and writes over SPI
led_blink.bin unchanged copy from test/bitstreams/v1_4
gpio_extender_14pin.bin unchanged copy from examples/
gpio_extender_14pin.py driver from the repo, pin numbers fixed for Shrike-fi
fpga_config_raw_test_video.mp4 video of the main test on both boards
spi_check_test_video.mp4 video of the SPI test on both boards
The README lists the sha256 of the bitstreams so you can confirm I did not change them.
How I tested
I wrote a small MicroPython script that sends the bitstream to the FPGA on its own, without using the shrike module. I did this because one of my boards still has the normal MicroPython on it and has no shrike module. This way the exact same code runs on both boards, so the comparison is fair.
The pin numbers come from the shrike module inside your own firmware:
EN GPIO9 PWR GPIO8
SPI id 2, sck GPIO12, mosi GPIO11, miso GPIO13
SS GPIO10
The steps are the same as in archive/shrike_micropy/shrike_fpga.py. Pull SS low, turn EN and PWR off, turn them back on, toggle SS, then send the whole bitstream.
The bitstream is test/bitstreams/v1_4/led_blink.bin straight from your repo. I copied it to both boards and checked the sha256 on each one. Both are the same, 46408 bytes.
The script first blinks the MCU LED on GPIO21 five times. That is only to prove the board is running and that I am looking at the right board. Then it sends the bitstream and waits 15 seconds.
Good board (still on the normal ESP32_GENERIC_S3 MicroPython):
firmware: ESP32_GENERIC_S3
STEP 1 -- MCU LED blinks 5 times -> yes
STEP 2 -- sending led_blink.bin
sent 46408 bytes
FPGA LED blinked -> yes, about once per second
Bad board (running your SHRIKE_FI build, v1.28.0-preview.175):
firmware: SHRIKE_FI
STEP 1 -- MCU LED blinks 5 times -> yes
STEP 2 -- sending led_blink.bin
sent 46408 bytes
FPGA LED blinked -> no, it stays dark the whole time
You can see this in fpga_config_raw_test_video.mp4 in the zip.
So the board that fails is the one with your firmware on it. And it is not just my script. It fails the same way with your own functions, shrike.flash() and shrike.blink_fpga():
[Shrike] FPGA reset done
[Shrike] Starting to program FPGA ...
[Shrike] Flashing: led_blink.bin
[Shrike] FPGA programming done.
It says it worked, but the LED never comes on.
I also tried both led_blink.bin files in the repo, the one in test/bitstreams/v1_4 and the different one in examples/led_blink/bitstream. Same result with both.
The SPI test shows the same split
I also loaded gpio_extender_14pin.bin on both boards, wrote a few patterns, and read them back. This one is in spi_check_test_video.mp4.
Good board:
wrote 0x3FFF read 0x3FFF ok
wrote 0x1555 read 0x3555 MISMATCH
wrote 0x2AAA read 0x3AAA MISMATCH
wrote 0x1234 read 0x3234 MISMATCH
wrote 0x0F0F read 0x3F0F MISMATCH
These bits did not match:
bit 12 GPIO17 physical pin 8
bit 13 GPIO18 physical pin 9
The other 12 bits read back correctly.
The values change depending on what I write, and most bits come back exactly right, so the FPGA on this board is answering. The two bits that are off are on header pins with nothing connected to them.
Bad board:
wrote 0x3FFF read 0x3FFF ok
wrote 0x1555 read 0x3FFF MISMATCH
wrote 0x2AAA read 0x3FFF MISMATCH
wrote 0x1234 read 0x3FFF MISMATCH
wrote 0x0F0F read 0x3FFF MISMATCH
Always 0x3FFF, whatever I write. Nothing comes back at all. The first line only looks right by accident, because 0x3FFF is also what you read from a loose line that is pulled high.
This also shows my driver is fine, since the same driver gets real data out of the good board.
Other things I checked on the bad board
EN (GPIO9) and PWR (GPIO8) are both high, before and after sending the bitstream.
MISO does not look driven. I read it twice, once with the internal pull-down on and once with the pull-up on. It just follows the pull both times, with CS high and with CS low:
CS=1 (deselected): pulldown=0 pullup=1
CS=0 (selected): pulldown=0 pullup=1
So nothing on the FPGA side is holding that line.
At first I thought the FPGA was stuck in reset. 0x3FFF is the value top.v puts into gpio_dir_reg while rst_n is low, and rst_n is on GPIO16, which is also the LED pin. But then I looked at the led_blink source. It has no reset input at all, and LED_en and clk_en are both tied to 1'b1. So reset cannot explain it.
Two questions
-
Is there anything else I should try before I decide the FPGA on this board is dead? Different timing, a longer power off, anything like that?
-
Can I check from the MCU side whether the FPGA really loaded?
flash()always prints “FPGA programming done”, but I think that only means the bytes were sent out. The pinout doc says pin 6 is SPI_SO (MISO) / CONFIG. Is there a done signal I can read there?
I can put a scope on the config test pads if that helps. Just tell me what to look for. If it does turn out to be a hardware fault I would like to get a replacement, but I am happy to run more tests first.
Thanks.
shrike_fi_fpga_test.zip (6.5 MB)