STMCUBEIDE Debug with Segger j-link stops starting the session after code change

[SWitz]

Strange Problem. I have a code who is running. But... If i change a part of the code (compile without error) and i start debugging

he Shutting down....

Some time i only insert a dummy command, like inc of a variable, it works.

Please see attached file.

I hope you have some suggenstions.

SEGGER J-Link GDB Server V7.66 Command Line Version

JLinkARM.dll V7.66 (DLL compiled May 18 2022 15:52:58)

Command line: -port 2331 -s -device STM32L433CC -endian little -speed 8000 -if swd -swoport 2332 -vd

-----GDB Server start settings-----

GDBInit file:         none

GDB Server Listening port:   2331

SWO raw output listening port: 2332

Terminal I/O port:       2333

Accept remote connection:   localhost only

Generate logfile:       off

Verify download:        on

Init regs on start:      off

Silent mode:          off

Single run mode:        on

Target connection timeout:   0 ms

------J-Link related settings------

J-Link Host interface:     USB

J-Link script:         none

J-Link settings file:     none

------Target related settings------

Target device:         STM32L433CC

Target interface:       SWD

Target interface speed:    8000kHz

Target endian:         little

Connecting to J-Link...

J-Link is connected.

Firmware: J-Link Ultra V5 compiled May 2 2022 09:00:06

Hardware: V5.00

Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB

Checking target voltage...

Target voltage: 3.30 V

Listening on TCP/IP port 2331

Connecting to target...

Connected to target

Waiting for GDB connection...Connected to 127.0.0.1

Reading all registers

Read 4 bytes @ address 0x0802A2C8 (Data = 0xD9F92B01)

Reading 64 bytes @ address 0x20009FC0

Received monitor command: ReadAPEx 0x0 0xF8

O.K.:0xE00FF003

Received monitor command: ReadMemAP 0x0 0xE00FFFD0 0x8 0x0

O.K.:0x00000000,0x00000000,0x00000000,0x00000000,0x00000035,0x00000004,0x0000000A,0x00000000

Read 4 bytes @ address 0x0802B804 (Data = 0xB085B480)

Read 4 bytes @ address 0x0802B804 (Data = 0xB085B480)

Reading 64 bytes @ address 0xA5A5A580

WARNING: Failed to read memory @ address 0xA5A5A580

WARNING: Failed to read memory @ address 0xA5A5A5B9

Connected to 127.0.0.1

Reading all registers

Read 4 bytes @ address 0x0802A2C8 (Data = 0xD9F92B01)

Reading 64 bytes @ address 0x20009FC0

GDB closed TCP/IP connection (Socket 1092)

Restoring target state and closing J-Link connection...

GDB closed TCP/IP connection (Socket 1076)

Shutting down...

[SWitz]

Additional Information about cubeide

Version: 1.10.1

Build: 12716_20220707_0928 (UTC)

 CodeTogether Collaboration 2022.2.2.202209131701 com.genuitec.eclipse.codetogether.feature.feature.group Genuitec, LLC

 DevStyle (includes Darkest Dark Theme) 1.11.0.202206271604 com.genuitec.eclipse.theming.core.feature.feature.group Genuitec, LLC

 DevStyle - Icon Designer 1.11.0.202206271604 com.genuitec.eclipse.theming.designer.feature.feature.group Genuitec, LLC

 DevStyle with CodeTogether Bundle 1.11.0.202206271604 com.genuitec.eclipse.theming.feature.feature.group Genuitec, LLC

 Doxygen binaries 1.8.16.v20191028-2041 org.gna.eclox.doxygen.feature.feature.group Andre Bossert

 Eclipse Color Theme 1.0.0.201410260308 com.github.eclipsecolortheme.feature.feature.group GitHub

 Eclox 0.13.0.v20191027-1934 org.gna.eclox.feature.feature.group Andre Bossert

 IndentGuide 1.6.3.20210418-0342 net.certiv.tools.indentguide.feature.feature.group Certiv Analytis

 STM32CubeIDE 1.10.1 com.st.stm32cube.ide.mcu.rcp.product null

[Bob S]

> WARNING: Failed to read memory @ address 0xA5A5A580

> WARNING: Failed to read memory @ address 0xA5A5A5B9

Those addresses look suspicious. The usual cause of "I just added one line and the program crashes" (or in your case the debugger exits) is stray memory access (i.e. NULL pointers or using uninitialized RAM). Could be overwriting the GPIO config registers on the JTAG/SWD pins and disabling the debug port.

Check the Cube-generated MX_***_Init() functions (MX_GPIO_Init, etc.) and make sure they declare all their local structures with "= {0}" to make sure the entire structure has know data.

Enable the MPU and dis-allow access to memory starting at 0x0, and enable the "bus" and "memory management" faults in SCB->SHCSR. Those two typically are disabled by default and get changed into "hard fault" which can mask the actual fault. See if you get a memory exception.