STM32 PROGRAMMER 2.14 DOWNLOAD FAIL --> custom external loader

[SafeDev]

Hi all,

we have developed an external loader to write a SPI flash. Start address is 0x9000000

The loader was written following the ST procedure and disabling all interrupts.

All works good but for file of dimension greater than 500k the download fail.

For example for a file of more or less 196k we saw from our custom UART terminal that Cube programmer split the file into two pieces of roughly 90k. At the end of the first chunk we correcly see that Cube programmer change write address to 0x90016300

Bytes written: 90368
Bytes written: 90624
WRITE RECEIVED ADDRESS 90016300

BYTES TO WRITE 91028
Bytes written: 90880
Bytes written: 91136

When the download fail (with a file of 900k) the programmer split the file in pieces of roughly 300k

From consolle output --> BYTES TO WRITE 339968

We see that file download is going on up to 112896 then the Programmed perform a reset and start to write again from the first location!!!

Bytes written: 112640
Bytes written: 112896
INIT --> Reset occurs!!!
WRITE RECEIVED ADDRESS 90000000 ---> start again!!!

Have you any hints?

Thank you

Best regards

[Tesla DeLorean]

Having a hard time rationalizing the numbers

90000000 to 900162FF would be 0x16300 / 90880 bytes

You don't mention what memories or configuration (single / dual). Assuming a Single QSPI memory, you're going to need to decompose the writes into 256 byte pages, max length of 256 bytes, on 256-byte boundaries.

You must wait for each page write to complete. The pages can be written as multiple pieces, but you can't span the page boundary.

The size of the buffers, and ping-pong behaviour relates to the amount of free SRAM left after the loader.

You can observe the loader side of the interactions via the UART you debug with.

You can observe the STM32 Cube Programmer side via the Verbose Logging, Level 3

You'll need to align the failure between the two. Determine if the Loader is returning the error, or the programming tool. In NOR_FLASH it's going to need the Memory Mapped read to work, where as in SPI_FLASH mode it can use Read() function. At the Write() level of your own loader you can do a read-back verification of what you successfully wrote to Flash vs what was supplied. Start validating there, perhaps use a direct comparison/reporting, or CRC the memory coming into Write() before you start, and check that against the QSPI memory before you leave.