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

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.

What is the part id supposed to be? It seems to just be a string that is output in io_config.py.

The spring pins are a major pain, but a good test socket costs $100 a pop and is a bit over-budget for us.

What does a typical run look like? I still just keep seeing the "flashing Caravel" over and over again

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...         ==
===================================================================

Ok. Enabling debug, I get the correct mfg/product and JEDEC values still.

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

?

Can confirm it's not seeing any pulses.

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.

Looks like that file is valid and matches the copy locally

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?

Two

Yes, D3 is the GPIO LED.

Yeah, there's nothing on it

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.

I've got a scope, will do that

It's supposed to be a 10MHz CMOS clock.

Hmmm

That's what you're reading, or that's the bandwidth of your scope?

It's a nice 100ns period. It was just my settings.

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).

just for my curiousity, do you have a source file too?

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.

SCK doesn't toggle so nothing seems to be running