Skip to main content
Jeroen3
Senior
January 6, 2021
Question

NSRT asserted multiple times when initiating debug session

  • January 6, 2021
  • 3 replies
  • 2383 views

In STMCubeIDE 1.5.1

When starting a debug session NRST is issues multiple times causing a bit of undefined behavior depending on the target and code.

First it resets and has the old program run a bit.

Then it loads the new program.

Which is lets run a bit.

Before initiating a debug session.

Is there a way that I can improved this behavior to have only one reset for download, keep it halted, and then starting a debug session without running the program first?

0693W000006He2PQAS.png

This topic has been closed for replies.

3 replies

waclawek.jan
Super User
January 6, 2021

I don't use CubeIDE but surely there's a comprehensive and concise manual for it somehwere. Or not.

Normally, debuggers/programmers have a selection of hard reset/soft reset/no reset (hot plug) startup (each having different behaviour with regard to reset, success of connection under adverse circumstances, program download, etc.).

JW

Jeroen3
Jeroen3Author
Senior
January 6, 2021

I looked into it, and it seems like downloading and debugging are two separate process launches.

I suspect this is just a limitation of Eclipse with GDB over a TCP/IP connection compared to Keil.

LaurentL
ST Employee
January 6, 2021

If you select connect under reset, it should halt the core and not run any instructions.

Did you try with STlink Openocd ?

Is it the same behavior ?

Sure there are several resets but appli should not run.

With Openocd, downloading and debugging are done with the same tool (STLink gdb server uses STM32CubeProgrammer for downloading).

Rgds,

Laurent

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Jeroen3
Jeroen3Author
Senior
January 7, 2021

I've tried with OpenOCD. This looks better!

OpenOCD:

0693W000006HmPHQA0.pngST Link GDB:

0693W000006HmPqQAK.pngI think it first checks the chip type before actually doing anything, and because it launches the debugger twice for that it can't hold reset.

It can be annoying locking up i2c devices and such because it gets resets again so quickly.

waclawek.jan
Super User
January 7, 2021

OpenOCD has also several reset settings, see manual.

JW