https://open-source-silicon.dev logo
Title
m

Matthew Guthaus

02/01/2023, 5:14 PM
I'm still stuck on setting up the GPIO. I originally get past the Winbond SRAM error and it does a few iterations of flash/erase, but depending on the die it quits eventually with the Winbond SRAM error. It seems to correctly flash anywhere from 3-10 times like this before failing:
*** flashing Caravel

Caravel data:
   mfg        = 0456
   product    = 11
   project ID = 00000000

Resetting Flash...
status = 0x00

JEDEC = b'ef4016'
Erasing chip...
done
status = 0x0
t

Tim Edwards

02/01/2023, 9:10 PM
We have worked through a number of issues with calibration, and you might want to try updating with what we pushed just a few minutes ago (as well as checking the instructions in the README file, which have been updated as well recently). However, I haven't encountered the "Winbond SRAM" error except in chips that were completely broken. Jeff encountered it once where the Caravel board was pushed far enough down that the flex pins were pushing against the Nucleo board. For the messages you posted: The "Caravel data" comes from communicating with the onboard housekeeping SPI and reading off the ID numbers. The JEDEC number comes from putting the housekeeping SPI into "pass through" mode and communicating directly with the SPI flash chip and reading off its ID number. Note that both of these steps go through the housekeeping SPI, whose controls are on GPIO[1-4], which can get overwritten by a program running off of the flash. So after programming, if those GPIO are being put in a state that is incompatible with the SPI, then communication becomes impossible until the chip is power cycled, and also powered up while in reset (with the reset button pressed down) so that the program doesn't keep running and overwriting the GPIO[1-4] configuration. The housekeeping SPI can be accessed while the chip is in reset. This power-up-in-reset procedure is coded into the Nucleo board routines, and for the chips I've tested it has been very reliable. However, the key phrase there is "for the chips I've tested", since I only have two daughterboards in my posession.
m

Matthew Guthaus

02/01/2023, 9:23 PM
What is the part id supposed to be? It seems to just be a string that is output in io_config.py.
The second part about the GPIO is very useful, thank you, @Tim Edwards
My earlier Winbond SRAM errors were due to bad connections with the spring pins. They are still a bit sketch since two of them are somewhat bent -- I believe they came that way actually.
t

Tim Edwards

02/01/2023, 9:34 PM
The spring pins are a major pain, but a good test socket costs $100 a pop and is a bit over-budget for us.
The "project ID" is supposed to be the same number as the user ID that was given to the project at time of submission, but there was an error in the setting of the value in the SPI register that was fixed for a later MPW run. For MPW-two, they will all display zeros.
But if you're referring to "part name" passed to the "make run" command, then it's just a way to identify the calibration pattern for a specific chip. There is a number related to the project ID that is pasted on the daughterboard---mine says "D3". Different chips belonging to the same project are not separately identified anywhere. We have been marking the boards with a permanent marker, so I now have "D3_2" and "D3_6", and these names are what I pass to "make run".
1
Doing that puts a comment on the first line of the configuration definition file with that string in it, which is useful since various pieces of code look for a configuration file with a generic name, so even if you name the file "gpio_config_def_D3_2.py", you still have to copy it to "gpio_config_def.py" to use it in a program, so it's helpful for the file to have a comment line at the top to differentiate it.
m

Matthew Guthaus

02/01/2023, 9:47 PM
What does a typical run look like? I still just keep seeing the "flashing Caravel" over and over again
I still get this:
~/mpw2_test/caravel_board/firmware_vex/nucleo (main)$ make run PART=B3_2
mpremote connect /dev/ttyACM0 exec "import io_config; io_config.run('B3_2')"

===================================================================
== Beginning IO configuration test.  Testing LOW IO chain...     ==
===================================================================

*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
*** flashing Caravel
Winbond SRAM not found
t

Tim Edwards

02/01/2023, 10:02 PM
It's supposed to look something like this (ignore the fact that I'm running the high chain first; I swapped the order while testing an obscure issue):
Tim@khachaturian(nucleo)> sudo make run PART=D3_2
mpremote connect /dev/ttyACM0 exec "import io_config; io_config.run('D3_2')"
 
===================================================================
== Beginning IO configuration test.  Testing HIGH IO chain...    ==
===================================================================
 
*** flashing Caravel
gpio[36] >> Passed
gpio[35] >> Failed
*** flashing Caravel
gpio[36] >> Passed
gpio[35] >> Passed
gpio[34] >> Passed
gpio[33] >> Passed
gpio[32] >> Failed
*** flashing Caravel
gpio[36] >> Passed
gpio[35] >> Passed
gpio[34] >> Passed
gpio[33] >> Passed
gpio[32] >> Passed
gpio[31] >> Passed
gpio[30] >> Passed
gpio[29] >> Failed
*** flashing Caravel
gpio[36] >> Passed
gpio[35] >> Passed
gpio[34] >> Passed
gpio[33] >> Passed
gpio[32] >> Passed
gpio[31] >> Passed
gpio[30] >> Passed
gpio[29] >> Passed
gpio[28] >> Passed
gpio[27] >> Passed
gpio[26] >> Passed
gpio[25] >> Passed
gpio[24] >> Passed
gpio[23] >> Passed
gpio[22] >> Passed
gpio[21] >> Passed
gpio[20] >> Passed
gpio[19] >> Passed
**** IO Configuration Test for high Chain PASSED!!
 
===================================================================
== HIGH IO chain test complete.  Testing LOW IO chain...         ==
===================================================================
m

Matthew Guthaus

02/01/2023, 10:03 PM
Ok. Enabling debug, I get the correct mfg/product and JEDEC values still.
I guess I have to dig in more what the flash test is doing.
t

Tim Edwards

02/01/2023, 10:10 PM
Routine
run()
calls
choose_test()
which calls
exec_data_flash()
which prints the "flashing Caravel" message. After that it calls
run_test()
which prints the
gpio[x] >> Passed/Failed
message. It is trying to read pulses off of each GPIO output off of the management GPIO pin (the one connected to the LED), and if it does not see any pulses, it returns without printing anything. . . which might be what's happening in your case? The program being flashed is
config_io_o.hex
and is supposed to be generating pulses on that pin. Maybe there's a problem with
config_io_o.hex
?
m

Matthew Guthaus

02/01/2023, 10:18 PM
Can confirm it's not seeing any pulses.
t

Tim Edwards

02/01/2023, 10:18 PM
So it seems like it is seeing the Caravel chip and is able to write to the SPI flash. But after that, it seems that the program is not running, which could have various causes. The first thing to check would be if the hex file
config_io_o.hex
on the Nucleo board is valid.
🙌 1
If at any point you ended up recompiling the
config_io_o.hex
file, then that just brought RISC-V compiler toolchain issues into the mix. If you're using the one that was in the repository, then it cuts down on the possibilities.
m

Matthew Guthaus

02/01/2023, 10:23 PM
Looks like that file is valid and matches the copy locally
I'm using the standard one from the repo
The one diff I do have is the st-flash command. I don't have a "--connect-under-reset" option and I think someone suggested using "--reset" instead.
t

Tim Edwards

02/01/2023, 10:27 PM
I'm pretty sure that if that part wasn't working right then it wouldn't be able to run the test at all. If you don't see any pulsing on the management GPIO (LED) line, then it's the chip that isn't working. How many different daughterboards have you tested?
m

Matthew Guthaus

02/01/2023, 10:27 PM
Two
Is D3 the GPIO LED on the caravel board?
t

Tim Edwards

02/01/2023, 10:30 PM
Yes, D3 is the GPIO LED.
m

Matthew Guthaus

02/01/2023, 10:30 PM
Yeah, there's nothing on it
t

Tim Edwards

02/01/2023, 10:31 PM
Check the clock going into the chip (
xclk
at the bottom of the development board). The housekeeping SPI can operate without a clock running (which would allow the SPI flash to be programmed without a clock running), but the chip won't run a program without it.
m

Matthew Guthaus

02/01/2023, 10:32 PM
I've got a scope, will do that
It's ~3Hz but seems to oscillate. What is it supposed to be?
t

Tim Edwards

02/01/2023, 10:37 PM
It's supposed to be a 10MHz CMOS clock.
m

Matthew Guthaus

02/01/2023, 10:37 PM
Hmmm
I might be undersampling then
40kHz 🙂
t

Tim Edwards

02/01/2023, 10:41 PM
That's what you're reading, or that's the bandwidth of your scope?
m

Matthew Guthaus

02/01/2023, 10:43 PM
It's a nice 100ns period. It was just my settings.
(I've not used this digilent soft scope very much)
t

Tim Edwards

02/01/2023, 10:50 PM
Try this really basic test. Copy the attached
blink.hex
file to the
blink/
directory. Then, from the
nucleo/
directory, run the following:
sudo make flash FILE=../blink/blink.hex
That much should get the red LED on the Caravel board blinking at a rate of about 1Hz (basic sanity check).
m

Matthew Guthaus

02/01/2023, 10:53 PM
just for my curiousity, do you have a source file too?
oh it's in the repo
The flash target now runs io_config too
Yeah, nothing from a basic blink test
I'm wondering if my funky spring pin happens to be the GPIO pin
These pins seem to be a vccd pin and Caravel_CSB
t

Tim Edwards

02/01/2023, 11:18 PM
I should have provided the output:
Tim@khachaturian(nucleo)> sudo make flash FILE=../blink/blink.hex
cp ../blink/blink.hex /media/firmware.hex
sync
sleep 2
mpremote connect /dev/ttyACM0 exec "import io_config; io_config.run_flash_caravel()"
*** flashing Caravel
status Good
FYI, I don't have automount set, so I am manually mounting the Nucleo flash
mount /dev/sdf1 /media
(or something like that depending on the exact device name). Note that I have found that my mount is not set for write-through, so I have added
sync
to the Makefile target to make sure that the Nucleo board sees the same file that I think I wrote to its flash.
Also: You can put a scope probe on
SCK
at the bottom of the Caravel board (there are 5 vias in a row that are connected to the SPI flash pins) and should see it toggling when any program is running.
m

Matthew Guthaus

02/02/2023, 1:13 AM
SCK doesn't toggle so nothing seems to be running