Add reset MCU command to debug toolbar

[AHugh.2]

Hi,

Is it possible to add a MCU reset command to the debug toolbar? I.e. a button that does a pause then "monitor reset" type sequence? Of course I can do this manually in the debug console, but it'd be nice to have a button to do it, to complement the full restart button.

Thanks!

[TDK]

This one doesn't work? What is a monitor reset type sequence?

 

[AHugh.2]

Thanks, but I am referring to Cube integration in VSCode not CubeIDE.

"monitor reset" is a command you give to GDB to tell it to reset the target, without it going through the reconnect, and flashing the image again.

 

[Nawres GHARBI]

Thanks @AHugh.2   for the proposal

Ticket created for this change request 

[ADunc.1]

Yup, definitely need that reset button.  In my case I use a bootloader.  Debugging programs just the application.  But cant properly run the application with it going through the bootloader first.  So, need to be able to reset after programming to force the bootloader to be executed.

And besides, every debugger I have ever used has a reset button so you can quickly start again with reprogramming (which takes forever on a full flash H7!).

[vincent_grenet]

@AHugh.2 
Thank you for reporting this issue.
I’m happy to share an early teaser with you: the reset feature is already part of our codebase, and we plan to deliver it as soon as possible. Stay tuned!

[Ozone]

And I thought such a MCU reset command was standard ...

Just saying ...

[Florent V]

Hi @AHugh.2 , @ADunc.1 and @Ozone ,

The reset button is officially available in the latest 3.7.0 release.

By default, it will execute :

• monitor reset
• tbreak <runEntry attribute value>
• continue

However, you can customize these commands using the following attribute in your debug configuration

"quickReset": [
 "monitor reset",
 "tbreak main",
 "continue"
],

Kind Regards,
Flo

[Ozone]

As a remark ...

If the option "run to main" is disabled (i.e. the debugger should stop at the reset vector), a "reset MCU" should take that into account.

[Florent V]

Hi Ozone,

Thanks for the remark.

For info, without talking about "reset MCU" (aka "quickReset"), if the "runEntry" attribute is not set, then the program does not stop at startup. Otherwise, it would be blocking for users wanting to run their code.
In this case, it is easier to set the desired function in the "runEntry" attribute.

For the "quickReset", we chose to set a temporary breakpoint on the "runEntry" value or on "main" (if "runEntry" is not set). But again, it is entirely possible to customize this via the "quickReset" attribute.

And of course, if many agree with your remark, we can change our approach, no problem with that.

KR,
Flo

[Nawres GHARBI]

available now 

[AHugh.2]

Hi,

One observation, say I want it just to reset and not break on main, then I have put this in the lauch.json:

"quickReset": [
 "monitor reset",
 "continue"
]

So just ommitted the "tbreak main" line, but I find doing this allows only one reset then no other debug commands seem to work - can't pause, and pressing the quick reset button again results in it the button becoming disabled and that's it.

With tbreak in, no problems.

Thanks.

 

[Florent V]

The error comes from a desynchronization between the GDB client and the VSCode debug session.
During the reset, the GDB client correctly sends the "continue" command after the reset.
However, VSCode does not synchronize, so any new command from VSCode is not handled by the GDB client.

In the meantime, to avoid this behavior with quickReset: [monitor reset; continue], you must at least set a manual breakpoint in the code so that the GDB client hits it and synchronizes with VSCode.

Note:

• setting the breakpoint manually, rather than in the quickReset command, allows you to change the breakpoint before a reset.
• if you are hung, setting the breakpoint after the reset will not work because the GDB client is running and will not respond.

 

BR,
Flo

 

[AHugh.2]

Thanks for the response Florent.

In my case I was looking for a quick MCU reset and run to catch something with minimal "down-time". However it is not a big deal.