Issues on Debugging External Application Using ST-Link

[Chao]

Hi,

I am trying to debug an external application with an ST-Link coming together with my Nucleo-G070RB board. I tried all three available debugger probes in CubeIDE:  ST-Link (Open-OCD), ST-Link (ST-Link GDB Server), and Segger J-Link. they all failed.

The pins used for connecting the external application and ST-Link: VDD from target, GND, SWDIO, SWDCLK, Reset

The console messages when setting the debugger probe to ST-Link (Open-OCD:(

At debug start:

after clicking on Step-Over:

Error: Fail reading CTRL/STAT register. Force reconnect

Error: Fail reading CTRL/STAT register. Force reconnect

Warn : target STM32F103ZETx.cpu is not halted (gdb fileio)

Polling target STM32F103ZETx.cpu failed, trying to reexamine

Error: Fail reading CTRL/STAT register. Force reconnect

Examination failed, GDB will be halted. Polling again in 100ms

... ...

The console messages when setting the debugger probe to ST-Link (ST-Link GDB Server:(

The console messages when setting the debugger probe to Segger J-Link :

SEGGER J-Link GDB Server V7.92n Command Line Version

JLinkARM.dll V7.92n (DLL compiled Oct 31 2023 15:10:15)

Command line: -port 2331 -s -device STM32F103ZE -endian little -speed 4000 -if swd -vd

... ...

------Target related settings------
Target device: STM32F103ZE
Target device parameters: none
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little

Connecting to J-Link...
J-Link is connected.

... ...

Checking target voltage...
Target voltage: 3.31 V
Listening on TCP/IP port 2331
Connecting to target...
Connected to target

... ...

Read register r0 - r12, sp, lr, pc, xpsr  --- all OK

... ...

Received monitor command: reset
Resetting target
Downloading 484 bytes @ address 0x08000000 - Verified OK
Downloading 16060 bytes @ address 0x080001E4 - Verified OK

... ... 

Starting target CPU...
GDB closed TCP/IP connection (Socket 984)
Debugger requested to halt target...

ERROR: Cannot read register 15 (R15) while CPU is running
...Target halted (PC = 0x00000000)
Reading common registers: ERROR: Cannot read register 0 (R0) while CPU is running
Read register 'r0' (4 bytes) from hardware: 0xEFBEADDE
ERROR: Cannot read register 1 (R1) while CPU is running
Read register 'r1' (4 bytes) from hardware: 0xEFBEADDE
ERROR: Cannot read register 2 (R2) while CPU is running

... ...

error occurs on reading all other registers and memory

... ...

GDB closed TCP/IP connection (Socket 980)
Restoring target state and closing J-Link connection...
Shutting down...

This is my first time to use debugger in CubeIDE, so it might be a simple configuration issue.

Regards

Chao

[Pavel A.]

>Target device: STM32F103ZE

But you wrote, the board is  Nucleo-G070RB? Do you understand what this means? You have a STM32G0 there, not F1.

[Chao]

Yes, the target is F103ZET6 that is on another STM32 board. On the Nucleo-G070RB board, there is an ST-Link and a 6-pin SWD connector, the ST-Link can connect to G070RB on the board or connect to an external STM32 Mcu with proper jumper settings. When connnecting to the SWD connector, an external STM32 application can be programmed and debugged by use of the ST-Link.

[AScha.3]

Hi,

your first setup with ocd looks not bad, just try with lower speed + software reset , see:

Maybe your cables are long (> 20cm ? ) or you have EMI /spikes on ground, then always problems.

Try short (max. 20cm) wires, "good" ground (from same mains plug , no or small loops ).

[Chao]

Thank you for your reply!

Applied your setup (Debug probe of ST-Link GDB Server, lower speed of 1000KHz and software reset), but still got the "target no device found" error. Same error for all reset options but Connect under reset.

Then changed reset option to Connect under reset, and got the following result:

But when clicking on Step-Over the HAL_Init() function, error occurred:

The SWD connection cable is indeed long, about 70cm. But the flash download is OK, and the J-Link cable is even much longer (about 160cm), and the download has also completed successfully, all register readings are OK  before the Debugger halts the target. Therefore, I suppose that the debug failure was not caused by cable length or ground noise. The same J-Link has been used for debug on NXP Mcus (ARM Cortex M0+) for years before we switch to STM32 just days ago. The cable we are using with J-Link for production programming is more than 300cm, and it works well without any problems. 

[Pavel A.]

USB cables between the PC and St-Link/J-Link indeed can be 2-3m if good quality. The wires or ribbon cable from debugger to target should be up to ~ 20 cm.

[AScha.3]

About cable length, i just can tell from my experience:

here with st-link V3 mods, at its max. speed 24MHz and SWD at 12 Mbit: 20cm to target, 5m USB2 cable to PC .

+

With (old) j-link (12MHz) or st-link V2 (8MHz) : 20cm to target, 3m USB cable to PC.

[AScha.3 · Accepted solution]

So the connection to your F103 seems to work - until you do something wrong (in  HAL_Init() ).

1. Check connection (maybe need hardware reset or "under reset" ) with CubeProgrammer , to see just connection working.

2. Make new project with IDE , just set a useful clock tree and debug pins for SWD , generate code and start debug .

[Chao]

Found where the issue is:  by default, Cube chose "No Debug" for me, and I did not know there is such an option.

Thank you all!