Unable to restart a running debug session about cortex-debug HOT 13 CLOSED

Ok - I'll try to get an actual release with that fix out later tonight or tomorrow morning - then you can go back to the marketplace release. Will mark the issue as closed once the release is completed.

from cortex-debug.

Thanks for the report. I'll try to take a look as soon as possible. I don't think it is the target-async setting (although I don't think I actually need that in hind-sight, something left-over from the original base project).

Can you add "showDevDebugOutput": true to your launch configuration and try again and post the debug output log to somewhere like pastebin (just will probably be a bit much to put in a GitHub issue) for me to look at.

from cortex-debug.

Ah, I was wondering how to get debug output, interesting. Here it is:
https://pastebin.com/6wPBRGcG

From reading here https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Program-Execution.html

Note that when asynchronous execution is enabled, this command is asynchronous just like other execution commands. That is, first the ‘^done’ response will be printed, and the target stop will be reported after that using the ‘*stopped’ notification.

I see the done response but should we be waiting for the stopped notification?

As a test, I tried to add set target-async off in preLaunchCommands but this unfortunately failed with an error: "cannot change this setting while the inferior is running".

from cortex-debug.

Can you actually post one from the very beginning - I want to see the entire setup sequence that it is using. Also perhaps post the output from the "Adapter Output" view in the Output tab.

from cortex-debug.

Also - I have posted a v0.1.18-pre in the GitHub releases that has GDB async disabled - if you can try manually installing and running with that version it will tell me for sure if it is to do with the async responses. Very well could be a race-condition there that haven't encountered on other computer/probe/target combinations that I'm testing with or other people are using successfully.

from cortex-debug.

Ah, very cool, I didn't realize that adapter output was there. I won't be able to get to the logging and pre-release test till tomorrow but I'll let you know. Thanks!

from cortex-debug.

Ah, sorry, the output gets reset on a restart, here is the full log. https://pastebin.com/cym0tdnQ

Also, here is the adapter output. https://pastebin.com/9cCWBi3T

I tried the pre-release version. but that unfortunately did not work either. In fact "-exec-interrupt" didn't seem to work at all (since the "pause" feature) was also broken. In the log output all I would see "-exec-interrupt" with nothing following. The wording of the "-exec-interrupt" command is confusing on GDB's website https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Program-Execution.html but it looks like "-exec-interrupt" only works in async mode (based on the opening sentence on the webpage).

These are the asynchronous commands which generate the out-of-band record ‘*stopped’. Currently GDB only really executes asynchronously with remote targets and this interaction is mimicked in other cases.

I've clone the repo and started playing with it.

from cortex-debug.

This might break another feature, but what about just setting

response.body.supportsRestartRequest = false;

in gdb.ts?

This will cause the debugger to restart and reload the image (which is nice if the user has rebuilt the code with changes).

from cortex-debug.

Thanks for all the additional information. I expect it is a race condition that I'm not currently seeing on the hardware I am using (as it is with race conditions they can be hard to reproduce - as I am able to use J-Link and restart with all my target boards). I kind of expect this is a possibility in a couple of spots - but hadn't encountered it occurring yet and haven't had time to restructure it to make it easy for me to wait for the proper events in those cases. Hopefully I'll be able to get to work on this more seriously next weekend.

Is your target a pre-existing dev board - or something custom made? Might be able to recreate it if it is a board I can get my hands on easily that isn't too pricy.

Also - what type/version of J-Link are you using, and what J-Link tool versions? What OS and version?

What I expect will work right at the moment - is using the release version when you want to restart press pause first, waiting for it to actually stop, then press restart. I will try to make a fix for the race condition over the next couple of weeks so that it will work in all cases.

Thanks for the excellent report.

from cortex-debug.

Actually - just dawned on me what the likely problem with explicitly waiting for the event was before. Just pushed up a v0.1.18-pre2 - try that out - expect it will fix the problem. If it works I think the same basic fix will allow me to get the run-to-main on launch working properly as well.

from cortex-debug.

That worked perfectly! Thanks man!

from cortex-debug.

Ok - v0.1.18 should has been pushed to the marketplace. Update should be available soon. Thanks for all your help testing fixes.

from cortex-debug.

Just got the update from the marketplace. It works great, thank you!

from cortex-debug.