cubeprogrammer can not find masserase function

[keanlee0721]

I created an external flash STLDR file for my board, with STM32H750VB chip and W25Q64 QSPI FLASH. After copying the STLDR file to the cubeprographer directory, it can perform normal external flash read/write and sector erase functions. However, when selecting full chip erase, the cubeprographer prompts me "please select external loader before performing external full chip erase". But I am sure that my code contains the correct int MassErase (void) function, and I used the readelf command in Ubuntu environment to read the STLDR file I created, which also includes the MassErase function. But it seems that this function cannot be correctly detected by the cubeprographer. How can I locate the cause and solve this problem?
Wishing you peace

[BMB]

Upgraded to STM32CubeProgrammer v2.19.0. Same behavior.

[Tesla DeLorean]

Need to work on the Linker Script so isr_vector gets placed on 0x200 aligned boundary (notionally 0x20000200)

[BMB]

Not sure what the ISR vector table gets to do with all that. I had problems with interrupts (messing up already difficult debug) so I disabled and adjusted the code that it works completely without them. I am not exactly sure though at which moment of the story I did that. Let me see if that makes a diff (I doubt it :) ).

[BMB]

Put back the ISR table there ... and ... 

:)

My bet is that since MassErase is described as "optional" in the template .. it was not tested at some point of STM32CubeProgrammer, at least not with stld files made by STM32CubeIDE (I noticed most of them look like made with IAR ...

[nonoriri]

STM32CubeProgrammer GUI External Loader Full Chip Erase Failure Issue

I'm experiencing an issue with External Loaders created using CubeIDE when using STM32CubeProgrammer GUI:

Problem Description:

• STM32CubeProgrammer GUI fails to execute "Full chip erase" with custom External Loader
• Error message: "Please select external loader before performing external full chip erase"
• Issue occurs on both STM32CubeProgrammer v2.19.0 and v2.20.0

However, CLI works perfectly:

STM32_Programmer_CLI.exe -c port=SWD freq=4000 -el .\MyExternalLoader.stldr -e all
-------------------------------------------------------------------
                   STM32CubeProgrammer v2.19.0                    
-------------------------------------------------------------------
ST-LINK SN  : xxx
ST-LINK FW  : V3J15M7B5S1
Board       : STLINK-V3SET
Voltage     : 3.26V
SWD freq    : 3300 KHz
Connect mode: Normal
Reset mode  : Software reset
Device ID   : 0x450
Revision ID : Rev V
Device name : STM32H7xx
Flash size  : 128 KBytes
Device type : MCU
Device CPU  : Cortex-M7
BL Version  : 0x91
Mass erase ...
Mass erase successfully achieved

• CLI executes mass erase successfully
• Flash memory is properly erased to 0xFF (verified)

My Analysis: I suspect this might be a compatibility issue between STM32CubeProgrammer GUI and External Loaders built with CubeIDE (GCC toolchain). Official ST External Loaders appear to be built with IAR Embedded Workbench for ARM (EWARM), which may create binaries with different structures that the GUI specifically expects.

Could this be a bug where STM32CubeProgrammer GUI only recognizes MassErase functionality in EWARM-built binaries?

What are your thoughts on this issue?

[vaualbus]

Speaking on this I was never able to get a flashloader built with STMCubeIDE to work. had to switch to IAR to get mine working. Linker file is fine, code is the same as per IAR but still STMCubeIDE build loader just refuse to load at all, in my case it even fails on Loader_init function. Targeting U545 micro.

PS

At the end I was able to get i to work, partially let's ay. Had to enable opt (Os) so apparently STM32CubeProgrammer has some checks for the max amount of memory a flash loader can be? 

[BMB]

Quite possible. For example: it complains about the number of blocks in the external memory it can handle.

We are at the mercy of STM Cube Programmer development here.

The other solution is to extract the images destined to the external memory from ELF, write utility/script and a matching custom (private) loader (maybe make it a part of bootloader) using other interface than STLink (UART, USB).

This was the way my project would go anyway (the project kinda went away in the meantime :) ). We were not planning on having JTAG or STLink interface in the actual product.

I did something like that some time ago. It was by post-build script using objcopy and other "linuxy" binaries manipulation apps acting on the output HEX files. You lose some of the IDE Debug "goodies" regarding the objects in the External Memory, but they are not that reliable anyway. That is if you are not trying to execute from QSPI (if you are, then gods help you, because I cannot :) ).

In this case it was just TouchGFX assets + sound files and the plan was to get away from memory-mapped QSPI eventually, since we needed the external flash for other things like logging, device state storage and OTA firmware update images. We would lose the ChromeArt DMA (Graphic Accelerator) but that was OK, since we had to disable it anyway: it was not working great (DMA arbitration), the images on the display came with stray pixel lines here and there. The GUI was not very demanding (static screens, no animations, video etc. 480x320 16-bit color), so it turned out that ChromArt was not speeding it that much.