Help with CubeProgrammer in custom external loader when calling Write()

[Southbranch]

Hi!

I am developing a custom loader for a custom H7-board with a OSPI with a page size of 512 bytes (0x200). Naturally the programming via the Write() function needs to be optimized in programming whole pages aligned on boundaries and so on.

When debugging with a loading a testfile of 572 bytes (0x23c), the Write() is called twice with these input values from CubeProgrammer:

Write()--------------------
 Address: 0x70000000
 Size: 0x13c
Write()--------------------
 Address: 0x7000013c
 Size: 0x100

I have stated page size to 512 bytes in Dev_Inf.c so it does not make sense why the first call is not made with a size of 0x200 and the second call is made with the "rest" 0x3c..

For other tests it almost appear as CubeProgrammer calls Write() with "random size chunks" and naturally causing the programming to fail.

Have I missed something here, what logic is applied in CubeProgrammer?

[Tesla DeLorean]

The behaviour of STM32 Cube Programmer and ST-LINK Utilities is frequently at odds with how you might hope it should be. I wouldn't hurt my head to much with it. Factors like available RAM on the target can play a role.

The Write() function should always deblock the actual write into the requirements of the device, don't rely on the tools to be helpful in this regard, and honestly best they don't. Optimally you want the Write() to be as massive as possible for efficiency. Typically where the programmer splits available SRAM into two halves, filling one half via SWD/JTAG as you write the current half.

https://github.com/STMicroelectronics/stm32-external-loader/blob/main/STM32H7x_boards/MT25TL01G_STM32H747I-DISCO/Sources/Loader/Loader_Src.c#L91

https://github.com/STMicroelectronics/stm32-external-loader/blob/main/STM32H7x_boards/MT25TL01G_STM32H747I-DISCO/Sources/Library/stm32h747i_discovery_qspi.c#L438

 

[Tesla DeLorean]

This is also where the size of the loader impacts efficiency, as they typically share the same SRAM, a loader that's got 100KB of code in it will leave 28KB from 128KB, where as an 8KB loader will leave 120KB which might then ping-pong between two 60KB buffers.

For large QSPI/OSPI devices ST-LINK/V3 is strongly recommended for speed.

[Southbranch]

Many thanks!

I was afraid this was the case. I see now from your useful links that all of the page-programming-logic is put in the BSP_QSPI_Write() called by Write() via CubeProgrammer.

Also, thanks for your second remark about the loader's size, I'll definitely keep that it mind!