>>> ecp5.flashrd(0x340000,32) bytearray(b'3\x04\x05\x00\xb3\x84\x05\x003\t\x06\x00\xef\x00@v3\x08\x05\x003\x05\x04\x00\xb3\x85\x04\x003\x06\t\x00') >>> ecp5.flashrd(0x380000,32) bytearray(b'\x13\x02\x05\x00\x93\x84\x05\x00\x97\xc2\x06\x00\x83\xa2\x82\xd9s\x90R\x10s\x10@\x10\x93\x02@\x00cRR"')
@Dolu1990 @emard As I understand the conversation, the current hypothesis is that the flash rom gets in a confused state during FPGA load.
That brought back a memory of working on an i2c driver (h/w and s/w) a few weeks backs for the Cortex. To get it working, one of the things was to always reset the bus/devices. For i2c this means clocking the bus until all devices release the data line and then issuing a start and a stop condition, as a stop condition terminates any pending command.
I could imagine that the flash SPI bus may need something similar, like clocking it for n pulses followed by a "soft reset" command to the device (if such a command exists).
So maybe try:
Now I came across this, apparently JEDEC standard JESD252 specifies a method to reset an SPI flash chip. If I understand the figure correctly, CLK is held low (in mode 0) and CS is used to clock the chip. The data line must carry 0-1-0-1 for a reset to happen:
mmc part, and it it lists partitions, do "boot".
Ok, I've done a bit more reading and also scanned the ISSI datasheet. You guys probably already thought of all the below, but just to make sure. My current understanding of the "all cases covered" reset sequence is as follows:
Larry Wall once observed that "given enough eye balls, all bugs are shallow". It seems to me we don't have enough eye balls yet :^)
@ThomasHornschuh What OS is the machine with the SDCard reader natively using?
It is my Laptop with Windows 10 and an internal SD card reader, but I think I will give @lawrie recommendation of using an USB reader I try. VMWare can pass USB transparently to VMs (it works e.g. with USB disk drives), but the SD Card reader in Laptops are often a Realtek PCIE chip