Ignoring all my detours I did, the sucessfull way for me was
At the end it this is very simple and straight forward, and will take maybe 30 Minutes if you do it right at the first try
>>> ecp5.flashrd(0,32) bytearray(b'\xff\x00Lattice Semiconductor Corporat')
>>> 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: