Marus / cortex-debug

Visual Studio Code extension for enhancing debug capabilities for Cortex-M Microcontrollers
MIT License
1k stars 239 forks source link

Blackmagic Probe: not called "detach" or "quit" on Stop. #517

Closed DrZlo13 closed 1 year ago

DrZlo13 commented 2 years ago

Calling these functions is very important, since only then the debug register and breakpoints are cleared.

haneefdm commented 2 years ago

First, I don't have a BMP or used one ever. I would appreciate a donation. I am the only one maintaining this debugger.

Have you enabled debug to see if this is indeed the case? In launch.json, do a "showDevDebugOutput": true and look at the output in the Debug Console.

There could be a bug the intent is to follow what gdb recommends/insists. We do the following regardless of the server (all commands go via gdb since we never talk to the server directly)

All of the above is according to the gdb specification and what VSCOde buttons present the user presses. It has been this way ever since I remember. Not saying there might be a problem.

If we started the server process, then we also try to kill it using operating system methods if it voluntarily did not exit after a pretty large timeout. For BMP, this does not apply.

We don't even have a mechanism to make the session ending process custom to a gdb-server

disconnect should be the gdb-servers command that severs the ties between gdb/us.

DrZlo13 commented 2 years ago

What I see in the Debug Console when I click Stop:

60-break-delete
61-target-disconnect
GDB -> App: {"token":60,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}
GDB -> App: {"outOfBandRecord":[{"isStream":false,"type":"notify","asyncClass":"thread-exited","output":[["id","1"],["group-id","i1"]]}]}
GDB -> App: {"outOfBandRecord":[{"isStream":false,"type":"notify","asyncClass":"thread-group-exited","output":[["id","i1"]]}]}
GDB -> App: {"token":61,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}
-gdb-exit
GDB -> App: {"outOfBandRecord":[],"resultRecords":{"resultClass":"exit","results":[]}}

As you can see, there are no "detach" or "quit" commands. The problem is that clearing the debug registers in the BMP works only with "detach" or "quit", "disconnect" does not reset them and further normal work with the device is impossible without a power reset (and this is not always possible).

Maybe I don't see some setting that would end the debugging session correctly, with "detach"? My launch config looks like this:

    {
      "showDevDebugOutput": true,
      "cwd": "${workspaceRoot}",
      "executable": "./build/STM32.elf",
      "name": "Blackmagic Flipper Zero",
      "device": "STM32WB55RG",
      "request": "launch",
      "type": "cortex-debug",
      "servertype": "bmp",
      "runToMain": true,
      "svdFile": ".vscode/STM32WB55_CM4.svd",
      "BMPGDBSerialPort": "//./com18",
      "targetId": 1,
      "interface": "swd",
    },

And yes, I am happy to donate the BMP to make its support better, how can I do this?

haneefdm commented 2 years ago

detach is not mandatory and has a different meaning. We do that if that is what the user wants but not otherwise. This is a super important detail. detach means keep the program running as after a disconnect Without a detach, it means the gdb-server should leave the program in its current state (usually paused).

In VSCode. F5 mean Stop (kill) which is disconnect without detach. Opt-F5 means detach and disconnect. This is according to the Spec from Micosoft and even gdb has the same policy. If you hove the 'Stop' button you can actually see both options. There are many people relying on this behavior, so this is not going to change without a lot of justification.

https://microsoft.github.io/debug-adapter-protocol/specification.

If the program starts with an 'attach' type session the default for the button also changes to detach.

But I see disconnect and exit.

haneefdm commented 2 years ago

Btw, there is no quit command for gdb. disconnect is the only thing in the gdb protocol that applies for the gdb-server to do what it takes to cleanup.

This is what every other gdb-server I know (openocd, pyocd, jlink, etc.)

DrZlo13 commented 2 years ago

Oh, i see. Got it. When asked for "attach" everything works correctly. The only thing I see as questionable is that the rest of the methods I've tried (openocd with stlink, ST-LINK server with stlink) don't seem to obey this logic. Both the "attach" and "launch" methods leave the debug register in the correct state when the session ends.

Also found strange behavior when trying to launch "attach" or "launch" after the previous "attach". The "launch" request after "launch" works fine, "attach" after "launch" also works. I'll investigate this a little more.

My attach config is:

    {
      "showDevDebugOutput": true,
      "cwd": "${workspaceRoot}",
      "executable": "./build/STM32.elf",
      "name": "Attach Blackmagic Flipper Zero",
      "device": "STM32WB55RG",
      "request": "attach",
      "type": "cortex-debug",
      "servertype": "bmp",
      "svdFile": ".vscode/STM32WB55_CM4.svd",
      "BMPGDBSerialPort": "//./com18",
      "targetId": 1,
      "interface": "swd",
    },

I still want to know how I can donate the BMP.

haneefdm commented 2 years ago

And yes, I am happy to donate the BMP to make its support better, how can I do this?

You can contact me through github. My profile/email is public.

OpenOCD has a bug where it does the wrong thing on a disconnect especially if threads are involved. Some implementations have this fixed. JLink always seems to do the same thing regardless of what we do. The program always continues, I think. We don't have custom code for every gdb-server.

We send the same commands via gdb and servers who obey the extended-remote protocol are supposed to do the right thing. Have you contacted the people who make BMP? Or, are you the one?

If you hover on the button to end the session, you will see the distinction image

The terminology MS used on the hover is a bit wonky but the protocol specification is clear and that is what we look at as the API and try to accommodate what the API asks for -- we have no idea if an API triggered the session ending it or a physical button push. We are command-line program that gets requests from VSCode

haneefdm commented 2 years ago

I don't have much experience with the ST-link server, so no idea what it does

DrZlo13 commented 2 years ago

Hello, have you receive BMP? If so, can you test you test the behavior I'm talking about when you hit stop after attach and attach afterwards?

haneefdm commented 2 years ago

I have received it but I don't know how to use it. All I got is two Nucleo boards F429ZI & H745ZI-Q, these don't even have a 10-pin connector it seems.

I also have a PSoC™ 6 WiFi-BT Pioneer Kit which doesn't seem to be supported. It does have a 10-pin connector. Do you have support for this device?

haneefdm commented 1 year ago

This is very old and I am closing it. If it is still a problem, please file a new issue. Currentluy, we do support detach and it is regardless of the gdb-server. It is up to the server to do the right thing. Some do, and some dont.