Debugging Flash Bootloader and External Flash Application - Can't Set Breakpoint

[David George]

Hello all

I have a STM32H730 project on a custom board.

I have two W25Q16JW 2MB Flash connected to the OctalSPI in Dual-Quad mode.

I have created a Flashloader ".stdlr" for my external Flash - its all working great in Cube Programmer and I can erase/program/debug a application from CubeIDE too.

I have an Application program running in my External Flash (XIP mode) - I can debug this project fine.

I have a small Bootloader program running in internal STM Flash (128K Flash) - I can debug this project fine.

My issue is when trying to debug both .elf files going from from Bootloader to Application.

(Reference : https://github.com/ethanhuanginst/STM32CubeIDE-Workshop-2019/tree/master/hands-on/09_BOOT-APP)

I can start CubeIDE debugging in the Bootloader, step through my code and place breakpoints, but when I step into the Application and try and single step, or place a Breakpoint, I get this message;

Error: Failed to set breakpoint at address: 0x90003da8.

Error: Failed to set more breakpoints

PS. 0x90000000 is the External Flash memory address.

What could be preventing the debugger from placing these breakpoints?

Any help would be really appreciated.

Thanks

[Tesla DeLorean]

>>What could be preventing the debugger from placing these breakpoints?

The memory is not suitably mapped at the point you're trying to place them?

External memory really should be brought up in SystemInit(), but ST's completely bodged that with the HAL/CUBE halfarsery, where things don't actually get done until deeper into main() and HAL_Init(), etc. long past the C and Debugger initialization windows.

The app code should not reconfigure the clocks, external memory, and related pins. That would typically need to get done previously, once, in the loader.

In KEIL one can use Debug Scripts to mechanically bring up external memory for the debugger, CubeIDE might facilitated this via calling the Init() function in the External Loader, might be options/settings relative to that in the project meta-data, check..

If you break-point / run-to-main() of the loader (your 128KB) the external memory is probably not viable yet, whilst would be if initialized in SystemInit()

[David George]

Hi, thanks for the reply

The external memory (OctoSPI) is initialised in the bootloader well before I jump to the application code. I can see the contents of the external Flash in the memory window fine.

If I step into the application code in "Instruction Stepping Mode" I can single step the machine code fine, it even keeps the .c source code window in sync. So it must be loading the app's .elf file okay.

It just refuses to set a breakpoint.

My app code does not modify clocks or anything else low-level already configured by the bootloader, I'm just calling HAL_Init() again which I have to.

Are you suggesting the external flash (OctoSPI) should be initialised in the bootloader's SystemInit() function? The earliest I could do it after the clocks have been configured.

[Uwe Bonnes]

What debugger? For gdb, what does "mem info "tell? Does the gdb-server map 0x90000000? If not mapped as FLASDH, maybe gdb tries to set a RAM breakpoint!

[David George]

Hi, yes GDB debugger (ST Link hardware).

How do I get the mem info/gdb-server's map?

> info proc mappings
> Not supported on this target.

Thanks

[Uwe Bonnes]

Sorry, not mem info but "info mem". E.g. for stm32f767"

(gdb) info mem
Using memory regions provided by the target.
Num Enb Low Addr High Addr Attrs
0 y 0x00000000 0x00004000 rw nocache
1 y 0x00200000 0x00220000 flash blocksize 0x8000 nocache
2 y 0x00220000 0x00240000 flash blocksize 0x20000 nocache
3 y 0x00240000 0x00400000 flash blocksize 0x40000 nocache
4 y 0x08000000 0x08020000 flash blocksize 0x8000 nocache
5 y 0x08020000 0x08040000 flash blocksize 0x20000 nocache
6 y 0x08040000 0x08200000 flash blocksize 0x40000 nocache
7 y 0x20000000 0x20020000 rw nocache
8 y 0x20020000 0x20080000 rw nocache
(gdb)

[David George]

Hi, so the external flash isn't listed in "info mem", just the internal Flash and ITCMRAM

info mem
Using memory regions provided by the target.
Num Enb Low Addr High Addr Attrs
0 y 0x00000000 0x08000000 rw nocache
1 y 0x08000000 0x08100000 flash blocksize 0x1000 nocache
2 y 0x08100000 0xffffffff rw nocache

I thought by using the command 'add-symbol-file' to add my Application it would load the memory regions from that .elf file too

Run Commands : add-symbol-file ../Application/dbg/application.elf 0x900002D0

[Uwe Bonnes · Accepted solution]

No! Gdb server  needs to set up the memory map. With the map your gdb server provides, 0x90000000 is rw and so gdb will use memory breakpoints that will not work in (external) flash.

[David George]

Thank you that worked!  By manually adding my external flash I can now set breakpoints there. Now I just need to automate this process..

info mem
Using memory regions provided by the target.
Num Enb Low Addr High Addr Attrs
0 y 0x00000000 0x08000000 rw nocache
1 y 0x08000000 0x08100000 flash blocksize 0x1000 nocache
2 y 0x08100000 0xffffffff rw nocache
delete mem 2
warning: Switching to manual control of memory regions; use "mem auto" to fetch regions from the target again.
mem 0x90000000 0x900FFFFF ro
info mem
Using user-defined memory regions.
Num Enb Low Addr High Addr Attrs
0 y 0x00000000 0x08000000 rw nocache
1 y 0x08000000 0x08100000 flash blocksize 0x1000 nocache
1 y 0x90000000 0x900fffff ro nocache

[David George]

..I just added the following to the Debug Configuration->Startup->Run Commands :

add-symbol-file ../M6-SG-Application/dmg_xip/M6-SG-Application.elf 0x900002D0
delete mem 2
mem 0x90000000 0x900FFFFF ro