QSPI external loader for STM32H750VBT6

[ronnietango]

I have a custom PCB using STM32H750VBT6 MCU and QSPI memory chip S25HL512TFAMHI010. I have written an external loader file as per the instructions in the STM32 MOOC [I tried to put a link here but the forum doesn't let me]. 

Testing the QSPI driver in STM32CubeIDE works fine, but when I try to write to the external memory using the .stldr file in STM32CubeProgrammer (v2.13.0), it returns "Error: failed to download the file". The console output is below:

 17:07:43:167 : Memory Programming ...

 17:07:43:176 : Opening and parsing file: myFile.bin

 17:07:43:176 : File  : myFile.bin

 17:07:43:176 : Size  : 1.60 MB 

 17:07:43:176 : Address : 0x90000000 

 17:07:43:177 : Erasing memory corresponding to segment 0:

 17:07:43:177 : Memory erase...

 17:07:43:178 : halt ap 0 Status = 0

 17:07:43:179 : halt ap 1 Status = 32

 17:07:43:179 : halt ap 2 Status = 32

 17:07:43:355 : Erasing external memory sectors [0 6]

 17:07:43:356 : Init flashloader...

 17:07:43:356 : halt ap 0 

 17:07:43:366 : run ap 0 

 17:07:43:367 : halt ap 0 

 17:07:43:380 : Loader sector erase...

 17:07:43:398 : run ap 0 

 17:07:49:146 : halt ap 0 

 17:07:49:151 : Download in Progress:

 17:07:49:182 : Size  : 1675808 Bytes

 17:07:49:182 : Address : 0x90000000 

 17:07:49:262 : halt ap 0 Status = 0

 17:07:49:263 : halt ap 1 Status = 32

 17:07:49:263 : halt ap 2 Status = 32

 17:07:49:337 : Loader write range...

 17:07:49:788 : Init flashloader...

 17:07:49:789 : halt ap 0 

 17:07:49:820 : run ap 0 

 17:07:49:820 : halt ap 0 

 17:07:49:821 : run ap 0 

 17:07:54:885 : halt ap 0 Status = 0

 17:07:54:895 : halt ap 1 Status = 32

 17:07:54:895 : halt ap 2 Status = 32

 17:07:54:895 : Loader write range...

 17:07:55:328 : halt ap 0 

 17:07:55:335 : Error: failed to download Segment[0]

 17:07:55:341 : Error: failed to download the File

I have tried the workaround suggested in this post - ["Custom-external-loader-failed-to-download-segment-0" on STM32 website - again I am unable to post a link for some reason] - but this did not help.

I also tried using STM32CubeProgrammer to do a Full Chip Erase of the external memory. This claims to be successful (almost instantly), but in fact the contents of the memory are not erased. Console output below:

 17:15:49:069 : MASS ERASE ... 

 17:15:49:074 : Flash erase...

 17:15:49:074 : halt ap 0 Status = 0

 17:15:49:074 : halt ap 1 Status = 32

 17:15:49:074 : halt ap 2 Status = 32

 17:15:49:234 : Init flashloader...

 17:15:49:234 : halt ap 0 

 17:15:49:273 : run ap 0 

 17:15:49:273 : halt ap 0 

 17:15:49:273 : Loader mass erase...

 17:15:49:275 : run ap 0 

 17:15:49:347 : halt ap 0 

 17:15:49:348 : Mass erase successfully achieved

 17:15:54:617 : UPLOADING ...

 17:15:54:619 : Size  : 1024 Bytes

 17:15:54:619 : Address : 0x8000000

 17:15:54:619 : Read progress:

 17:15:54:647 : Data read successfully

 17:15:54:648 : Time elapsed during the read operation is: 00:00:00.010

I suspect that "Status = 32" is some sort of error code, but I'm unsure how to debug this further - any suggestions greatly appreciated!

[Tesla DeLorean]

Test all your BSP code outside of the loader, write a test framework so you can debug and test all the functionality.

With the tools set the logging level to 3, this however only provides detail at the interface (API) level.

.

Instrument your loader code to use available serial port, or screen, etc to provide information and telemetry about what's happening internally. What functions are being called, what parameters, what registers/status you're getting from the QSPI chip. This is the only way to "debug" what's happening inside the loader, you aren't going to be able to debug it in the debugger and single stepping it. See advice in point one above.

>>I suspect that "Status = 32" is some sort of error code,

It's being reported before calling the external loader's initialization, so not clear what it's complaining about. Perhaps loading the code into RAM? or parsing the ELF object file. Probably wouldn't move the chip loaders from older versions, that should be fixed/addressed already.

[Tesla DeLorean]

I think I have some of these S25HL, or equivalents, in my parts box.

https://github.com/cturvey/stm32extldr

What pin configuration are you using for the QSPI on your board?

[ronnietango]

Thanks for the quick response. Pin configuration is:

QSPI_CLK - PB2

QSPI_NCS - PB6 

QSPI_BK1_IO0 - PD11

QSPI_BK1_IO1 - PD12

QSPI_BK1_IO2 - PE2

QSPI_BK1_IO3 - PD13

I have tested all the individual functions of the driver (Erase, Write, Read...) individually in STM32CubeIDE and they seem to be fine - I will try to add some code to print to the serial port for debugging purposes now

[Tesla DeLorean · Accepted solution]

Ok, that seems like the NUCLEO-144 pining, I have a fixture for that.

The API is not very forgiving, and the documentation/examples are poor. Most of ST's own loaders seem to be developed without a lot of the Cube/HAL baggage.

There's excessive calling of the initialization routines, KEIL's implementation at least brackets the Init/Uninit around larger transactional blocks of work. ie does Erase, Write and Verify in a single pass.

[Tesla DeLorean]

Turns out I have S25FL512S parts, which should be rather similar, but doesn't support the 0xB7 command to switch to 4-byte / 32-bit addressing mode, but rather requires different command variants.

https://www.infineon.com/dgdl/Infineon-S25FL512S_512_Mb_(64_MB)_3.0_V_SPI_Flash_Memory-DataSheet-v20_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ed046ae4b53

I ended up getting the Keil .FLM version working, and will port to the .STLDR platform shortly

https://github.com/cturvey/stm32extldr/tree/main/h7_s25hl512

[Tesla DeLorean]

https://github.com/cturvey/stm32extldr/blob/main/h7_s25hl512/CLIVEONE-S25FL512S_STM32H7XX-PB2-PB6-PD11-PD12-PE2-PD13.stldr

[Tesla DeLorean]

The S25HL01GT SOIC16 and S25HL02GT BGA24 parts came in from DigiKey yesterday so I'll assess those in the coming weeks.

The industry looks to be pivoting to the BGA24 to accommodate the stacked-die configurations, makes boards more complex and harder to solder.

[SMoon.2]

@ronnietango​ were you able to get it working? I'm in a similar spot where my individual commands are working when running a test program, but the external loader is giving me the same error as you.