Hi @Matt Venn can i get ur help on this?

what chip is this for?

I am using chip 2211Q-R @Matt Venn

do you see the errors when you type the command?

LED does not blink and the Winbond SRAM not found error comes

@samarth jain: That's an odd one because the

make

process is seeing the chip; you got back a part number with the

0006

prefix for MPW-6, so all that looks correct. This seems to be a new issue that I have not seen before. Have you tried multiple parts, and do you get the same behavior on all of them? If so, then you should install a header on the 6 pin J7 and use that with jumper wires to wire the SPI flash directly to the FTDI and program it that way (@jeffdi should be able to send you a link with the instructions for that); if that doesn't work, then it's a board level error. If the development board itself works but all assembled parts fail to program, then I am at a loss for ideas and we will need to debug the problem thoroughly.

I can sometimes solve the 'winbond sram not found' error by plugging and unplugging the usb cable

@Tim Edwards so this error is with the board and not my chip? what are part in pcb can cause this issue?

Please answer my questions before you infer anything about the error. I don't know what it is yet.

@Matt Venn @Tim Edwards I Tried a different chip and it works.

in my experience, your new errors are because the firmware is too big

This is blink example code.are we expected to see these errors with the blink.hex provided ? @Matt Venn

no, if you've not changed the example code, then you shouldn't see any read compare errors

i used this code directly https://github.com/efabless/caravel_board/tree/main/firmware/chipignite/blink @Matt Venn .also my led starts to blink even after these errors. i used caravel_hkflash.py script to load the hex.any suggestions i can check the flash issue @Tim Edwards?

@samarth jain: Okay, ignore what I said before. There is some kind of address mismatch in the verification stage. It is always comparing a long string of data against a short string of data. Where it advances the block and says that it is comparing at address 0x100, the shorter block is showing data continuing from where the last short block left off, which is definitely less than 0x100 bytes. It looks like it programmed correctly, though, and you might be able to get by with just ignoring the verification failures.

If the flash fails, it might just be running the previously loaded program

I don't think it failed, though. It reported success on programming and read back the correct data---it just seems to have started offsetting the address location in the verification report.

@Tim Edwards yes I slowed the blink and it does work. I think meantime I can continue but I am interested to know what causes these address error