STM32L4 -> L5 port : breakpoints not hit and watch expressions fail (no usable debug symbols)

[Mohinish Naik]

──────────────────────────────────────────────

SUMMARY

──────────────────────────────────────────────

While porting an existing STM32L4 project to an STM32L562CE target, source-level

breakpoints are never hit and adding watch expressions fails with "No symbol in

current context". The target runs normally (no fault), and manual pause resolves

to a plausible source line, but no symbolic debug capability works. Behaviour is

identical across both the ST-Link GDB server and the SEGGER J-Link GDB server,

indicating a target/build-side cause rather than a debug-probe cause.

 

──────────────────────────────────────────────

ENVIRONMENT

──────────────────────────────────────────────

- Target MCU    : STM32L562CE (Cortex-M33, ARMv8-M), Device ID 0x472, Rev Z, 512 KB

- Target board   : External custom/eval STM32L5 board (self-powered, 3.3 V)

- Debug probe    : On-board ST-Link of a NUCLEO-L476RG, used to program the

           external L5 target via CN4 SWD (CN2 jumpers removed)

- ST-Link firmware : V2J47M34 (ST-LINK/V2-1)

- Host OS      : Ubuntu (Linux)

- IDE        : STM32CubeIDE

- Programmer    : STM32CubeProgrammer v2.18.0

- Debug transport  : SWD @ 4000 kHz

- Logging      : SEGGER RTT (SWD)

 

──────────────────────────────────────────────

SYMPTOMS

──────────────────────────────────────────────

1. Source-level breakpoints in application code are never hit.

2. Target does NOT enter Reset_Handler trap or HardFault_Handler — code executes

  normally, no fault.

3. Manual "Pause" halts the core and shows a correct-looking source line.

4. Adding a watch expression fails:

   -var-create: unable to create variable object

   -data-evaluate-expression count -> No symbol "count" in current context.

5. (Original secondary issue) SEGGER RTT logs do not appear in RTT Viewer.

 

──────────────────────────────────────────────

DIAGNOSTICS PERFORMED (and results)

──────────────────────────────────────────────

[RULED OUT] Security / protection state

 - TrustZone disabled via STM32CubeProgrammer CLI; verified TZEN = 0x0.

 - RDP = 0xAA (Level 0, no protection).

 - BOOT_LOCK = 0x0, NSBOOTADD0 -> 0x08000000, no write protection active.

 

[RULED OUT] Device identity / target selection

 - STM32CubeProgrammer auto-detects target correctly: 0x472 / STM32L5xx /

  Cortex-M33 / 512 KB (confirms SWD link + external target driven correctly).

 - Project target MCU is correctly set to STM32L562CE.

 

[RULED OUT] Wiring

 - NRST -> CN4 pin 5, VREF -> external board 3.3 V, GND/SWCLK/SWDIO connected.

 - External target self-powered.

 

[RULED OUT] Debug probe as root cause

 - Switching between SEGGER J-Link GDB server and ST-Link GDB server produces

  identical behaviour (breakpoints ignored, expressions fail).

 

I have attached sample project for reference.

[Ozone]

You are sure you talk about a debug build here, not a release one ?

If in doubt, you can look at the native output file (usually *.elf).
A debug version will contain all the source file names, symbols and relevant code lines.

[Mohinish Naik]

Yes, I am facing this issue in the Debug build. I checked the contents of the ./Debug/board_bring_up_STM32L562CE.elf file, and it does contain the source file names.

[Ozone]

So probably an issue with the IDE / project setup itself.
Mind you, the debug / release builds are usually initialized by the IDE with “debug build” enabled or disabled, but one can easily change this manually.

I don’t use Cube, so I can’t really comment on details.

But perhaps you can explain what “...porting an existing STM32L4 project to an STM32L562CE target, ...” means in this context.
Modifying an existing project is too much of a hassle most of the time, so I usually create a second project for the new target, and copy the sources over (or share them).