Debugging program in external flash XIP mode STM32N6
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-16 10:45 PM - edited ‎2025-04-17 1:02 AM
Hi,
I am trying to debug STM32N6 program loaded in external flash. When I started the debugger in the FSBL project I can put a breakpoint just before it jumps into application inside external flash. It is obvious I wont be able to see the symbols since it is not loaded. So I loaded my application elf file under debug_configuration/Startup/Load Image and Symbols (See attached image). When I start my debugging session, I encounter the following error and was unable to debug even FSBL code.
Board: STM32N6 DK
STM32CubeIDE: 1.17.0
Platform: Window
project: Template_XIP_FSBL (found under Stcube package for N6).
Here is the error:
STMicroelectronics ST-LINK GDB server. Version 7.9.0
Copyright (c) 2024, 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
InitWhile : Enabled
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Failed to read all registers from target
Failed to read all registers from target
Failed to read all registers from target
Failed to read all registers from target
Thanks
Solved! Go to Solution.
- Labels:
-
STM32CubeIDE
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-20 11:14 PM - edited ‎2025-04-21 12:01 AM
Hi @Ghofrane GSOURI,
UPDATE 1: I think I found the cause.
If we load the application symbols during the debugger's start-up sequence, GDB won't be able to resolve those addresses because the external flash isn't memory-mapped at that point (i.e., after a reset). I confirmed this by disabling symbol loading during start-up. Instead, I set a breakpoint just before the FSBL was about to jump to the application. Once the program counter hit that breakpoint, I manually loaded the application symbols using the add-symbol-file command in the Debugger Console. After doing this, I was able to see the source and symbol information when I hit pause.
Now, I need to figure out how to set breakpoints within the application itself. Simply placing breakpoints in the application code doesn't work at this stage.
UPDATE 2: I just need to add source dir and memory region at this point. Once we hit the breakpoint at JumpToApplication() enter following commands in Debugger console.
add-symbol-file "your application.elf location"
set directories "your application source code dir"
// check mem region in gdb
info mem
// if info mem output doesnt contains external flash regions, add those regions
// following address is for STM32N6 XSPI2
mem 0x70000000 0x7fffffff
// if above command gives error delete existing memory regions and add memory regions manually. That should follow linker script
// following command delete region 0
delete mem 0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-17 2:45 AM - edited ‎2025-04-17 2:49 AM
Hello @sai2
First make sure to add this
Select ST-LINK (OpenOCD) as the [Debug probe] in the debug configuration of the Template_ XIP_FSBL
Also let's try to generate the trusted binary, this could resolve the issue .
The binary file of the application that you want to load in the memory need to be signed.
This operation is done using the STM32_SigningTool_CLI.exe which is included in the STM32Cubeprogrammer package.
You an access this tool using one of two ways:
1- Under the STM32CubeIDE installation path: (Windows example) C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.2.0.202409170845\tools\bin\
2- Under the STM32CubeProgrammer path: (Windows example) C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin
To sign the binary we need to launch this command: STM32_SigningTool_CLI.exe -bin Template_XIP_AppS.bin -nk -of 0x80000000 -t fsbl -o Project-trusted.bin -hv 2.3 -dump Project-trusted.bin
This step could be done also from within the STM32CuebIDE tool using the post build command option as described below.
1-Right Click on Template_XIP_AppS(in Apps), [Properties]>[[C/C++ Build]> [Settings] [Build Steps]
2- Tap on the Post-build steps this command: C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.2.0.202409170845\tools\bin\STM32_SigningTool_CLI.exe -bin Template_XIP_AppS.bin -nk -of 0x80000000 -t fsbl -o Project-trusted.bin -hv 2.3 -dump Project-trusted.bin
3-Click on [Apply], then build the Template_XIP_AppS to generate Project-trusted.bin
after generating the trusted bin go to
select add in order to add Project_trusted.bin and make sure to choose the download address for the Themplate_FSBL_XIP :0x70100000.
Please check Readme under C:\Users\XXXXX\STM32Cube\Repository\STM32Cube_FW_N6_V1.1.1\Projects\STM32N6570-DK\Templates\Template_FSBL_XIP
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-20 6:31 PM
Hi @Ghofrane GSOURI ,
Thank you for detail steps but unfortunately, I am still unable to debug FSBL and Application together after I followed the steps that you provided.
Here is the output from OpenOCD.
Open On-Chip Debugger 0.12.0+dev-00600-g090b431b1 (2024-09-13-19:14) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V3J15M7 (API v3) VID:PID 0483:3754
Info : Target voltage: 3.280106
Info : clock speed 8000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : [STM32N657X0HxQ.ap0] Examination succeed
Info : [STM32N657X0HxQ.cpu] Cortex-M55 r1p1 processor detected
Info : [STM32N657X0HxQ.cpu] target has 8 breakpoints, 8 watchpoints
STM32N657X0HxQ.cpu in Secure state
Info : [STM32N657X0HxQ.cpu] Examination succeed
Info : gdb port disabled
Info : starting gdb server for STM32N657X0HxQ.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : [STM32N657X0HxQ.cpu] external reset detected
Info : accepting 'gdb' connection on tcp/3333
[STM32N657X0HxQ.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x18003a1a msp: 0x341037a0
Info : New GDB Connection: 1, Target STM32N657X0HxQ.cpu, state: halted
Info : accepting 'gdb' connection on tcp/3333
Info : New GDB Connection: 2, Target STM32N657X0HxQ.cpu, state: halted
Error: Failed to read memory at 0x70101100
Error: Failed to read memory at 0x70101100
Error: Failed to read memory at 0x70101100
Polling target STM32N657X0HxQ.cpu failed, trying to reexamine
Error: Failed to read memory at 0x70101100
Error: [STM32N657X0HxQ.cpu] Examination failed
Examination failed, GDB will be halted. Polling again in 100ms
Error: Failed to read memory at 0x70101100
Error: Failed to read memory at 0x70101100
Error: Failed to read memory at 0x70101100
Error: Failed to read memory at 0x70101100
Error: Size 2 not supported
Error: Size 2 not supported
Error: Failed to read memory at 0x70101100
Error: Size 2 not supported
Error: Size 2 not supported
Error: Failed to read memory at 0x70101100
Error: Size 2 not supported
Error: Size 2 not supported
Error: Failed to read memory at 0x70101100
Error: Failed to read memory at 0x70101100
Info : dropped 'gdb' connection
shutdown command invoked
Info : dropped 'gdb' connection
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-20 11:14 PM - edited ‎2025-04-21 12:01 AM
Hi @Ghofrane GSOURI,
UPDATE 1: I think I found the cause.
If we load the application symbols during the debugger's start-up sequence, GDB won't be able to resolve those addresses because the external flash isn't memory-mapped at that point (i.e., after a reset). I confirmed this by disabling symbol loading during start-up. Instead, I set a breakpoint just before the FSBL was about to jump to the application. Once the program counter hit that breakpoint, I manually loaded the application symbols using the add-symbol-file command in the Debugger Console. After doing this, I was able to see the source and symbol information when I hit pause.
Now, I need to figure out how to set breakpoints within the application itself. Simply placing breakpoints in the application code doesn't work at this stage.
UPDATE 2: I just need to add source dir and memory region at this point. Once we hit the breakpoint at JumpToApplication() enter following commands in Debugger console.
add-symbol-file "your application.elf location"
set directories "your application source code dir"
// check mem region in gdb
info mem
// if info mem output doesnt contains external flash regions, add those regions
// following address is for STM32N6 XSPI2
mem 0x70000000 0x7fffffff
// if above command gives error delete existing memory regions and add memory regions manually. That should follow linker script
// following command delete region 0
delete mem 0
