IceCore myStorm firmware

[AndyCap]

Ok, the issue is the RDY flag on status byte 1 of the flash.

so before sending bitstream:

AT25SF041 Flash is not ready
ERROR: AT25SF041 Flash Not Found

and after

AT25SF041 Flash is ready
AT25SF041 Flash Found

Any ideas why?

[Folknology]

Any ideas why?

You have to erase before writing and wait for the ready flag?

BTW you need to Write enable also..

Also check that all bits are not '1' that is just the previous issue of Ice40 pulling spio pins up..

[AndyCap]

The flash api will always return 0xFF if the RDY flag is 1.

The RDY flag turns to 0 when we send a valid bitstream to the ICE40.

Before that it is always 1, this is why we cannot access the flash.

[AndyCap]

from the data sheet:

RDY/BSY Bit
The RDY/BSY bit is used to determine whether or not an internal operation, such as a program or erase, is in progress. To poll the RDY/BSY bit to detect the completion of a program or erase cycle, new Status Register data must be continually clocked out of the device until the state of the RDY/BSY bit changes from a logical “1” to a logical “0”.

This doesn't make much sense, as at power on this bit is 1.

I have tried polling it but it is never going to 0 unless we program the ICE40.

[Folknology]

The flash api will always return 0xFF if the RDY flag is 1.

The RDY flag turns to 0 when we send a valid bitstream to the ICE40.

Before that it is always 1, this is why we cannot access the flash.

This sounds like symptom rather than cause, I think the cause is the Ice40 state..

[AndyCap]

So the ICE40 is holding the flash in some busy state?

[Folknology]

So the ICE40 is holding the flash in some busy state?

No it is holding the SPI pins high which corrupt and data to and from flash..

[lawrie]

I get the opposite effect:

lawrie@gigabyte:~$ cat /dev/ttyACM0 
<myStorm 0.601> 0x1F,0x84,0x01
0xFF,0xFF,0xFF

The first press of the mode button was done after power-on. The second after sending a bitstream.

[Folknology]

I get the opposite effect:

Do you have a valid flash image installed?

[lawrie]

Do you have a valid flash image installed?

Yes, but the interesting thing that was that pressing the mode button just after sending a bitstream, caused the 0xFFs.

[lawrie]

The plot thickens. It depends which type of bitstream I send. I have some that I built with icepack -s, so that they leave the flash in woken-up mode, so that XIP from flash memory works.

If I send one of those bitstreams, I get the 0xFFs. If I send one that was built without the -s flag, I get the valid flash id.

<myStorm 0.601> 0x1F,0x84,0x01
0xFF,0xFF,0xFF
0x1F,0x84,0x01

[Folknology]

<myStorm 0.601> 0x1F,0x84,0x01
0xFF,0xFF,0xFF
0x1F,0x84,0x01

Interesting I need to look deeper, my head is still deep in flash writing at the moment, any ideas why?

[lawrie]

Interesting I need to look deeper, my head is still deep in flash writing at the moment, any ideas why?

Not really, but it looks like you are right about some sort of interference from the ice40.

[AndyCap]

No it is holding the SPI pins high which corrupt and data to and from flash..

Ah, got you.

I checked the status byte (instead of the bit) and it was 0xFF as well, pesky ICE40!

[AndyCap]

Just so I get the right here:

The ICE40 loads the bitstream from the flash from address 0?

The {0x7E, 0xAA, 0x99, 0x7E} should be stored in the flash?

[Folknology]

The ICE40 loads the bitstream from the flash from address 0?

The {0x7E, 0xAA, 0x99, 0x7E} should be stored in the flash?

Yes this is correct AFAIK

[lawrie]

The ICE40 loads the bitstream from the flash from address 0?

The {0x7E, 0xAA, 0x99, 0x7E} should be stored in the flash?

Yes, that header must be there. Usually the 0xFF, 0x00, 0x00, 0xFF is also written to the flash, but as that is a comment, it is not necessary.

You can also store a multi-boot configuration produced by iclmulti at address 0, and it specifies where to get the bitstream from. The one I use is a warm boot variant that boots into a bitstream at address 0xa0, and that in turn can use SB_WARMBOOT to boot into a bitstream at 0x28000.

[AndyCap]

Ok, that was going to me my next question.

I think that the STM can only map memory (for XIP) to the first 256K of the external flash, so ideally it would be good to move the bitstream out of that memory.

[lawrie]

I think that the STM can only map memory (for XIP) to the first 256K of the external flash, so ideally it would be good to move the bitstream out of that memory.

Not sure why you would want to use the external flash for XIP of arm programs. Doesn't the STM32 have internal flash that you could use for that? I use it for XIP of Risc-V program from a SoC on the ice40. If you did want to move the bitstream out of the first 256KB of the external flash, I believe you could do it with icemulti, but the first 160 bytes in the flash memory is a header containing what Lattice calls applets, that specify where the actual bitstreams are, so you could not use that. Also there is only 512KB of flash to play with so you could only fit one bitstream in the flash memory above 256KB.

[Folknology]

Not sure why you would want to use the external flash for XIP of arm programs. Doesn't the STM32 have internal flash that you could use for that? I use it for XIP of Risc-V program from a SoC on the ice40. If you did want to move the bitstream out of the first 256KB of the external flash, I believe you could do it with icemulti, but the first 160 bytes in the flash memory is a header containing what Lattice calls applets, that specify where the actual bitstreams are, so you could not use that. Also there is only 512MB of flash to play with so you could only fit one bit stream in the flash memory above 256MB.

I think @AndyCap maybe thinking of using the Arm as the application core rather than a soft core SOC leaving max LUTs for the App, other folks have also expressed interest this idea, it certainly has some performance benefits for certain cases