Hello everyone. I was try to bring up my silicon today. I was following all the steps mention on Git Repo Readme by keeping in mind all the discussion had done on this channel. Initially i was having an error of Winbond SRAM not found. After providing the external power supply of 5V to board i was able to get to the flashing part but in that i got an error of Failed to receive ready signal from firmware. As i was looking to the log of the run i found out this line " Failed to parse flash type or unrecognized flash type" Do anyone have any idea about this error? Below is the snap attached

@hamza shabbir Is your part analog (Caravan) or digital (Caravel)? If it's analog, then you will get the error above unless you do

make run_analog

. If it's digital, then the usual reason for "Windbond SRAM not found" is that the board is pressed all the way down and the flexi-pins are colliding with the headers on the Nucleo board underneath.

@Tim Edwards My part is digital. And i have make sure that my board is not pressed all way down.

For the record, you should be seeing this: (see note below; the new firmware will probably not report the "Caravel data" values, although the JEDEC code should still be reporting

ef4016

).

Caravel data:
   mfg        = 0456
   product    = 11
   project ID = 00000000
 
Resetting Flash...
status = 0x00
 
JEDEC = b'ef4016'

yes that;s what i am trying to understand that why all of my values are zero

If nothing else appears to be amiss, you might want to try another daughterboard.

after changing the daughter board i am getting this following output. The error says "Failed to receive ready signal from firmware"

The

failed to receive ready signal

indicates a problem with the Nucleo board and has nothing to do with the Caravel chip. Also, it occurs to me that the modification to make the analog projects work was also done to the code for testing digital projects. That code bypasses the SDO from the housekeeping SPI, and so makes it impossible to read the manufacturer and product ID off of the caravel chip. So as long as you are seeing the correct JEDEC code (

ef4016

), then the Caravel chip (or rather the SPI flash chip connected to it) is being programmed properly.

but the JEDEC ID for other boards are all zero or all FF

At least the one in the screenshot above that read the correct JEDEC code was working correctly. The one that returned

Winbond SRAM not found

is not working correctly, and could be a dead part.

ok i will look into it more detail and will get back to you. One last question if the issue is with Nucleo board as you have mention so is there a way to program caravel silicon without nucleo board?

Yes, but there isn't a way to test the part for the configuration errors without the Nucleo board (or rather there is, but it is extremely labor-intensive). Be aware that several people (see, for example, the post from Proppy) have seen this same "Failed to parse flash type" error, so it may be something introduced in the most recent push of the code.

Everytime I change a daughterboard I reflash the nucleo software

But at least in my case, the error was with flashing the Nucleo software; I can't do

st-flash

.

Hello @Tim Edwards. Previously during our discussion i mention that i was stuck at the error of "Failed to receive ready signal from firmware". As per your reply you mention that the issue is from the Nucleo board, so after that i try to run the caravel board separately. After going through this channel discussion i found that @Matt Venn have mention few steps to test the caravel without nucleo board and by following that i was able to run the caravel_hkdebug.py and caravel_hkflash.py files and was able to read the correct JEDEC ID as well. After flashing through caravel_hkflash.py i again try to run the IO Configuration test using nucleo board. Again i faced the same error. After going through the discussion happen between you and @Matthew Guthaus i have run the following command to program the config_io_o.hex file into caravel. "python3 flash FILE=config_io_o.hex" I have monitor the following signals using oscilloscope SCK, CSB and XCLK. As you mention that the XCLK must be of 10Mhz, SCK must be toggling. I was able to get all that following characteristics. I have also added the snaps below. So let me know is this make sure that my Si is alive and not dead. Also i want to know if there is any way to run the IO Configuration Test without Nucleo Board.

There are several ways to program and run the caravel chip without the Nucleo board. The problem is that without the Nucleo board, characterization is a tedious process. You can follow the algorithm used for the Nucleo-based characterization, though. The method is just to work your way from channel 1 to channel 18, and from channel 36 to channel 19 (channels 0 and 37 always work without modification, and so do not need to be tested). The goal is to determine if there is an independent or a dependent hold violation going into each GPIO control block (it's always one or the other, although there are cases that are on the edge and flip randomly between the two; these chips are basically untestable unless you can run at a low enough voltage that the problematic state stops becoming flaky. Often that's not possible, and you have to give up on that one and move on to another chip). From a program flashed onto the SPI flash, you'll want to get each GPIO to configure into a state

1100000000001

(management controlled output), and then toggle that output continuously and detect that toggling externally. If everything were working perfectly on the chip, then you would program that value into the register for the GPIO you wanted to test and initiate the transfer (through

reg_mprj_xfer

). But for each independent hold violation, that series of bits shifts backwards by 1 bit into the neighboring channel's configuration. For each dependent hold violation, you have to replace any occurrence of

10

in the sequence with

11

(runs of

1

have to be lengthened by 1).