After updating to CubeIDE 1.8 and CubeProgrammer to 2.9 my custom external loader is not working anymore.

[JureL]

Hey,

today I update CubeIde to 1.8 (with new CubeProgrammer 2.9) and noticed that I can no longer flash my external QUADSPI memory as I used to before in version 1.7. I made custom external loader following this guide : https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/external_QSPI_loader.html

Is there anything I need to change in my loader ? Or there is new bug present ?

I get this console output:

 
STMicroelectronics ST-LINK GDB server. Version 6.0.0
Copyright (c) 2021, STMicroelectronics. All rights reserved.
 
Starting server with the following options:
        Persistent Mode            : Disabled
        LogFile Name               : D:\Work\STM32CubeIDE\Projects\OB_TP-H7\V1_0\OB_TP-H7\Debug\st-link_gdbserver_log.txt
        Logging Level              : 31
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Enabled
        SWD Debug                  : Enabled
        InitWhile                  : Enabled
 
COM frequency = 24000 kHz
Target connection mode: Under reset
Reading ROM table for AP 0 @0xe00fefd0
Hardware watchpoint supported by the target 
ST-LINK Firmware version : V3J9M3B5S1
Device ID: 0x450
PC: 0x8004d40
ST-LINK device status: HALT_MODE
ST-LINK detects target voltage = 3.29 V
ST-LINK device status: HALT_MODE
ST-LINK device initialization OK
Stm32Device, pollAndNotify running...
SwvSrv state change: 0 -> 1
Waiting for connection on port 61235...
Waiting for debugger connection...
Waiting for connection on port 61234...
Accepted connection on port 61234...
Debugger connected
Waiting for debugger connection...
Waiting for connection on port 61234...
GDB session thread running
GdbSessionManager, session started: 1
Accepted connection on port 61234...
Debugger connected
Waiting for debugger connection...
Waiting for connection on port 61234...
GDB session thread running
GdbSessionManager, session started: 2
Stm32Device, closeDevice() entry
GDB session, device event: 5
GDB session, device event: 5
Stm32Device, pollAndNotify stopped
Stm32Device, closeDevice() exit
 ------ Switching to STM32CubeProgrammer ----- 
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.9.0-RC01                  
      -------------------------------------------------------------------
 
ST-LINK SN  : 002400235553500F20393256
ST-LINK FW  : V3J9M3B5S1
Board       : STLINK-V3SET
Voltage     : 3.29V
SWD freq    : 24000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x450
Revision ID : Rev V
Device name : STM32H7xx
Flash size  : 2 MBytes
Device type : MCU
Device CPU  : Cortex-M7
BL Version  : 0x90
 
 
 
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a15960.srec
  File          : ST-LINK_GDB_server_a15960.srec
  Size          : 2331676 Bytes
  Address       : 0x08000000 
 
 
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 8]
Erasing memory corresponding to segment 1:
Erasing external memory sectors [0 307]
Download in Progress:
�������������������������������������������������� 0%
����������� 22%����������� 44%����������� 66%
 
Error: failed to download Segment[1]
Error: failed to download the File
 ------ Switching context ----- 
COM frequency = 24000 kHz
Target connection mode: Under reset
Reading ROM table for AP 0 @0xe00fefd0
Hardware watchpoint supported by the target 
ST-LINK Firmware version : V3J9M3B5S1
Device ID: 0x450
PC: 0x8004d40
ST-LINK detects target voltage = 3.30 V
ST-LINK device status: HALT_MODE
GDB session, device event: 6
GDB session, device event: 6
Stm32Device, pollAndNotify running...
GDB session, device event: 3
GDB session, device event: 3
GDB session, device event: 1
GDB session, device event: 1
GDB session terminated: Client connection lost
GdbSessionManager, session terminated: 2
Cleanup session: 2
GDB session disposed: 2
Received Ctrl-C from the client 
ST-LINK device status: RUN_MODE
Device not halted(0), performing Ctrl-C
GDB session, device event: 4
Device halted
GDB session terminated: Client connection lost
GdbSessionManager, session terminated: 1
GdbSrv, master session terminated, signal dispose
Shutting down...
Stopping port 61234
Received stop for port 61234, not accepting new connections.
GdbSrv, deInit entry.
GdbSessionManager, deInit entry.
ST-LINK device status: HALT_MODE
GDB session disposed: 1
GdbSessionManager, deInit exit
SwvSrv deInit entry
Stopping port 61235
Stopping port 61234

St link log file is also attached.

[JureL]

@mattias norlander​ I have my custom board with a custom external loader so you won't be able to reproduce this issue. I will try to reproduce it with one of the discovery boards. I'll get back to you as soon as I figure out a similar problem using discovery board.

[Sara BEN HADJ YAHYA]

Hello @Community member​ ,

Any updates about this issue with a DISCO board?

Regards,

Sara.

[JureL]

@Sara BEN HADJ YAHYA​ and @mattias norlander​ 

I tried to reproduce this issue on the STM32F769-DISCO board. I made an external loader following the same guide as for my custom board. Unfortunately I didn't manage to reproduce this issue (external loader worked in cubeprogrammer version 2.8 and 2.9).

After some testing with my custom loader I managed to fix it to work with cubeprogrammer version 2.8 and 2.9. I did some changes to Loader_Src.c file :

• added HAL_SuspendTick() before return statement of Init, Write, Sector Erase, Verify functions
• added HAL_ResumeTick() in beginning of Write, Sector Erase, Verify functions

I don't know if this is the right fix but it works.

Also my board runs on H7 device. In the attachment you can find the original and fixed Loader_Src.c file.

[mattias norlander]

We have seen in the past that some external loaders which were designed only with "programming tools" in mind does not properly clean up interrupts after they are done executing. This leaves the target in a dirty state. This dirty state is not a problem if the external loader is only used with a "programming tool" like CubeProgrammer.

When using the same external loader with CubeIDE, which has not only to program external/internal flash, but also to launch debug, then the lack of clean up turns into a problem.

So, not all external loaders are fit for purpose from a "debug" point of view, since this was not a requirement before introduction of CubeIDE. As soon as we discover such a bug with a boot loader, we try to fix it. We are also looking at options on how to validate the external loaders with "debug" use case in mind.

Internal ticket reference: 118502