Is there a possibility to read program counter via ST-Link or J-Link without causing a reset on STM32F103 devices with RDP active?

[stst9185]

On a serial product after a firmware update, there are some sporadic cases, where we get a hang up situation. It would be very helpful to know where exactly the program is stuck. According to ES0346 Rev. 6 chapter 2.8 it is possible to access program counter even with RDP set. How can I exactly read the value with CubeProgrammer + ST-Link (or alternatively with J-Link).

[Zainka]

There is, but I have never tested it myself

The gdb server supports -g, --attach

"This attaches to the running target. Attach is aimed to be used to connect to a running program in the device without doing a reset or downloading a new program."

How this works with a stuck MCU i am unsure but it is the place to start

https://www.st.com/resource/en/user_manual/dm00613038-stm32cubeide-stlink-gdb-server-stmicroelectronics.pdf

Breg

[stst9185]

Thank you for your reply, I tried to use the CUBE programmer with command line interface instead of gdb, as this seemed to be the easier way with the call STM32_Programmer_CLI.exe -c port=SWD HOTPLUG -coreReg

which should do the same. But I allways get a PC value of 0xFFFFFFFE, even if I connect a device running in normal programm execution. Perhaps I will try the gdb-server.

[TDK]

If you're using STM32CubeIDE:

To debug your program without downloading it:

Go to Debug Configurations... -> Startup -> select load image -> Edit... -> uncheck Download

To debug without resetting the device:

Go to Debug Configurations... -> Debugger -> in Reset Behavior, select "None"

[stst9185]

I use IAR, but I will try a similar path there,

thanks

[Uwe Bonnes]

Try to hotplug attach with a debugger. In gdb "info regs" will give you the registers, or to only read the PC " p $pc". Most important is, can you attach? Second important probaby ist that you do it manually and not rely on some IDE to show you the values. Probably that wil step into some read protection.

[Tesla DeLorean]

Instrument the obvious places code goes to die. Like the HardFault_Handler and Error_Handler, and anywhere you have unbounded while loops, so you're not working blind.

Perhaps check what routines are interrupted by the SysTick, see if it is stuck somewhere, or off in some unexpected code paths.​

​

[stst9185]

I will do these things, but as a first step, I would like to find out, where exactly the code hangs. So I tried to get the program counter with:

STM32_Programmer_CLI.exe -c port=SWD mode=HOTPLUG -coreReg PC

this gives the register values, and other values like SP make sense, but PC is always FFFFFFFE?!

Do you have some hint how to really get the PC?

[Tesla DeLorean]

I'd use an EXTI interrupt.

Another way may be to focus on the stack frame.

>>PC is always FFFFFFFE?

Sure it is not vectoring out of blank Flash?

[Uwe Bonnes]

The picture stille says "Software reset". Reset would destroy PC.

[stst9185]

Thanks for the tip, I didn´t recognize this first. I still wonder why there seems to be a reset although the mode setting is HOTPLUG.

[alister]

To fix this you'll have to change the code. If you can debug it in a secure laboratory, consider turning off RDP while you're debugging.

[stst9185]

Yes of course I have tried this as well, but my problem is, that the hang-up is not frequently enough to have a realistic chance to get it in the debugger, but it is too often for accepting it for our customers.