STM32H573 with Secure Manager non-secure app debugging issues

[Christian Keydel]

Our own non-secure application is based on "SMAK_Appli" in the STM32TRUSTEE-SM example and in principle, it works, but debugging is giving me issues. This is with STM32CubeIDE latest version and all tools software and firmware updated to their latest versions, too.

Issue 1: Using STLINK-V3 to start debugging, whenever there has been a code change, the first attempt results in a verification error (see log below) and the second attempt then works. This is 100% consistent and terribly annoying since starting the non-secure debugging session is very slow to begin with.

Issue 2: Using J-Link to start debugging, it claims flash was programmed (very fast) and debugging seems to work at first, but I found that flash programming was not effective. The flash content is always what it was programmed with using STLINK. So if I want to use J-Link, I have to program with STLINK (twice), then switch to J-Link but I cannot successfully program changed flash content with J-Link.

Are these issues know and are there any ways to improve?

STMicroelectronics ST-LINK GDB server. Version 7.11.0
Copyright (c) 2025, STMicroelectronics. All rights reserved.

Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 1
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled

Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.20.0                  
      -------------------------------------------------------------------



Log output file:   C:\Users\Chris\AppData\Local\Temp\STM32CubeProgrammer_a16476.log
ST-LINK SN  : 004D003A3234510633353533
ST-LINK FW  : V3J16M8B5S1
Board       : STLINK-V3SET
Voltage     : 3.22V
SWD freq    : 8000 KHz
Connect mode: Hot Plug
Reset mode  : Software reset
Device ID   : 0x484
Revision ID : Rev X
Error: Fail to read Flash Size
Device name : STM32H56x/573
Flash size  : 2 MBytes (default)
Device type : MCU
Device CPU  : Cortex-M33
BL Version  : 0xE4
SFSP Version: v2.5.0
Debug in Low Power mode enabled



Opening and parsing file: ST-LINK_GDB_server_a16476.srec


Memory Programming ...
  File          : ST-LINK_GDB_server_a16476.srec
  Size          : 236.95 KB 
  Address       : 0x0805E400


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [47 76]
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Error: Fail to read Flash Size
Download in Progress:


File download complete
Time elapsed during download operation: 00:00:21.709



Verifying...




Error: Data mismatch found at address  0x0805E404 (byte = 0x4D instead of 0xF9)


Time elapsed during verifying operation: 00:00:02.471


Error: Download verification failed


Encountered Error when opening C:\ST\STM32CubeIDE\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.2.200.202503041107\tools\bin\STM32_Programmer_CLI.exe
Error in STM32CubeProgrammer
Shutting down...
Exit.

[Jocelyn RICARD]

 Hello @Christian Keydel ,

I confirm that STM32CubeIDE with last version 2.0.0 in this context is not able to generate a real system reset which is problematic to debug the beginning of your code.

If you are using your board you need a way to manually trigger a system reset.

If you are using the STM32H573I-DK, you can either use the reset button or the reset command from teraterm (ALT-B). This reset is generated by the STLink embedded on the board.

Regarding updating firmware from debugger I don't reproduce this verification error. I have the same multiple error trace : Error: Fail to read Flash Size, and then "Download verified successfully".

As I'm on STM32CubeIDE 2.0.0 it using STM32CubeProgrammer 2.21. Could be the reason.

Best regards

Jocelyn

[Christian Keydel]

Hello @Jocelyn RICARD ,

I upgraded to CubeIDE 2.0 and it didn't improve things. The reset issue is known and I have put an __asm___("BKPT") at the beginning of main() to work around this and this works well so this is not the problem.

We also have a new hardware that uses a different type of STLINK and still, the issue persists so it's not only with one particular board, or one type of board, or one type of STLINK.

It could very well be a problem that only shows up with bigger downloads. As you can see in my log, my download crosses 30 sectors and is this big:

Memory Programming ...
File : ST-LINK_GDB_server_a01288.srec
Size : 237.67 KB
Address : 0x0805E400

Perhaps if you add a lot of random, dummy constant data to your example app you may be able to see it? This website can generate for example a 250 KB size array with random data for C that you could just drop-in and try:

https://yupana-engineering.com/online-c-array-generator

[Jocelyn RICARD]

Hello @Christian Keydel ,

I could reproduce your issue by increasing the size.

In fact after trying to find a workaround I just remembered there was an errata for this topic.

This errata is still valid on the version 2.0.0 of STM32CubeIDE.

You can find it here

Besically you need to add following lines:

set breakpoint always-inserted on
tbreak Reset_Handler
monitor reset
set breakpoint always-inserted off
si

in the debug configuration, tab startup in the Run commands window at the bottom

After adding these, the download works successfully and even reset is working :)

Best regards

Jocelyn

[Christian Keydel]

Hello @Jocelyn RICARD ,

Thanks but no, this does not fix it. What you saw (I assume) is that the second time you start debugging with the same build, flash programming verification works and the debugger starts. Try to change the programming data (e.g. change random data or change optimization level or program with release build in between) and it will fail again the first time.

Note that enough data needs to change for the effect to occur - if there is very little change (e.g. only a single byte changing) the effect may not happen.

Best regards,

Christian