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.

[mattias norlander]

Let us try to conclude whether the problem exist in CubeProg stand-alone also or if there is an issue in the interface between CubeIDE / CubeProg.

Reading your log-file we can see that CubeProg is invoked using the following command line arguments:

C:\ST\STM32CubeIDE_1.8.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.100.202110141430\tools\bin\STM32_Programmer_CLI.exe --connect port=SWD speed=fast sn=002400235553500F20393256 mode=UR reset=hwRst --extload C:\ST\STM32CubeIDE_1.8.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.100.202110141430\tools\bin\ExternalLoader\MX25L12833FM2I_TP-H7_STM32H753IIT6.stldr --download c:\path\to\project.elf –verify

c:\path\to\project.elf to be substituted with your path in the project...

Does that work? If so, then we have to analyze in the IDE-team.

If not, then the issue is probably in CubeProg it self...

If it did not work, could you also please try the CubeProg GUI version to perform the same operation?

You could also try to perform a mass erase on the flash, sometimes that helps...

Let us know your findings.

[JureL]

Hey @mattias norlander​ , I tried to run this command and got the same result.

In GUI version of STM32CubeProg 2.9 I also can't flash my program to board. Mass erase is also not helping. Check CubeProg GUI version log file in attachment.

But I noticed I can normally mass erase/sector erase/read and write data to external flash.

So there must be a problem with new STM32CubeProgrammer.

[mattias norlander]

Thanks for the tests!

Here are my train of thoughts:

1. stldr-file works in CubeIDE 1.7 but not 1.8.
   1. Makes me wonder whether this regression issue is inside CubeIDE 1.8.0 or CubeProg 2.9.0?
2. Test with only CubeProg 2.9.0 CLI (based on the screenshot I see you rely on the CubeIDE bundled CubeProg_CLI version). You get the same error.
   1. Thought: Could still be the re-packaging done by IDE-team that leads to issue. Hence asking for test in GUI version
3. GUI tests with CubeProg 2.9.0 shows same regression issue
   1. Thought: This test result further strengthens the suspicion that it could be a CubeProg regression.

That said, I don't want to jump to any conclusion.

I will pass this thread internally to someone in CubeProg team for further analysis.

@Nawres GHARBI​, could you have a look?

Kind regards, Mattias

[ADESC.1]

Hello,

Similar problem with internal flash?

I work with a STM32L4R9 project and TouchGFX. This device is 2MByte flash size, but debug parse elf file with only one MByte of à 1.9mByte binary code.

That works with CubeIde 1.7 but fails with new 1.8 and CubeProgrammer 2.9, only BANK1 is flashed.

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

    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.9.0-RC01          

   -------------------------------------------------------------------

ST-LINK SN : XXXXXXXXXXXXXXXXXXXXXXXXXXX

ST-LINK FW : V3J9M3B5S1

Board    : STLINK-V3SET

Voltage   : 3,30V

SWD freq  : 24000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID  : 0x470

Revision ID : Rev W

Device name : STM32L4Rxxx/STM32L4Sxxx

Flash size : 2 MBytes

Device type : MCU

Device CPU : Cortex-M4

BL Version : --

Debug in Low Power mode enabled

Memory Programming ...

Opening and parsing file: ST-LINK_GDB_server_RxvN6O.srec

 File     : ST-LINK_GDB_server_RxvN6O.srec

 Size     : 1 MBytes

 Address    : 0x08000000 

Erasing memory corresponding to segment 0:

Erasing internal memory sectors [0 255]

Download in Progress:

Error: failed to download Segment[0]

Error: failed to download the File

With CubeIde 1.7 sectors [0 417] are used

----------------------------------------------

And when flashing binary generated by CubeIde 1.7 with new STM32CubeProgrammer interface 2.9 :

 08:02:18 : Memory Programming ...

 08:02:18 : Opening and parsing file: XXXXXX.bin

 08:02:18 :  File     : XXXXXX.bin

 08:02:18 :  Size     : 1710704 Bytes

 08:02:18 :  Address    : 0x08000000 

 08:02:18 : Erasing memory corresponding to segment 0:

 08:02:18 : Erasing internal memory sectors [0 417]

 08:02:27 : Download in Progress:

 08:02:27 : Error: file size is bigger than the flash memory size.

 08:02:27 : Error: failed to download Segment[0]

 08:02:27 : Error: failed to download the File

Regards

[JureL]

@Community member​  so I'm not the only one with this problem.

@mattias norlander​ and @Nawres GHARBI​ any news about that ?

[mkrug]

Dear all,

I reported a similar problem on the Discovery STM32L5 board (https://community.st.com/s/question/0D53W00001EywtESAR) For me it is very likely due to the STMicroelectronics ST-LINK GDB server. Version 6.0.0. In CubeIDE 1.7 this was version Version 5.9.1. The standalone STM32CubeProgrammer (2.8 and 2.9) work in my case. So its more likely the combination STM32CubeIDE + ST-LINK GDB.

I actually disagree to consider this thread as 'answered' like it is shown in the overview.

Best Regards

Markus

[mattias norlander]

Do you have any minimal example projects where you can reliably re-produce the issue?

That would help the troubleshooting!

[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