Use with Cortex Debug

[stanczyk4]

Type: Feature Request

Is it possible to use this extension in tandem with cortex-debug https://github.com/Marus/cortex-debug? Cortex debug offers a lot of features im not seeing this tool offering, like RTT output, logging, and plotting. I would like to use this tools FreeRTOS viewer in tandem with cortex-debug.

[robotdad]

There is not an issue in having both installed, however they can't both be active at the same time for debug. The issue is that we are using different launchers. This configuration for Azure RTOS has options for either Cortex Debug or our extension, note the type value. Our extension uses the C++ debugger while Cortex Debug has their own launcher.

Perhaps there is a way to achieve some level of integration through DAP, we'll have to have a think about that.

[haneefdm]

I was about to embark on an RTOS viewer myself and I ran into a blog mentioning this extension.

Perhaps I can help. I maintain the cortex-debug extension. I can't see your implementation but I can see that you need the read memory DAP request to work and that can be done ASAP. We have our own read-memory and it predates the DAP specification and is a superset. I would like to get rid of our own SVD implementation (eventually :-)) as well.

Also wondering if your views support multiple (concurrent) sessions. This is becoming common in multi-core setups. All of our views now support multiple sessions. This also applies to having an RTOS running on each core. If not, something to consider.

I was also wondering if your Registers view tracks the current thread/frame in the CALLSTACK windows. I don't know how to (unless I create a fake Watch variable).

[aleun]

I was about to embark on an RTOS viewer myself and I ran into a blog mentioning this extension.

Perhaps I can help. I maintain the cortex-debug extension. I can't see your implementation but I can see that you need the read memory DAP request to work and that can be done ASAP. We have our own read-memory and it predates the DAP specification and is a superset. I would like to get rid of our own SVD implementation (eventually :-)) as well.

Not sure if I'm misunderstanding, but the ReadMemory DAP request is already available when using the "cppdbg" debug type since it's provided by MIEngine (see microsoft/MIEngine#1028).

Also wondering if your views support multiple (concurrent) sessions. This is becoming common in multi-core setups. All of our views now support multiple sessions. This also applies to having an RTOS running on each core. If not, something to consider.

Thanks for the suggestion. It's something we'll consider for the future.

I was also wondering if your Registers view tracks the current thread/frame in the CALLSTACK windows. I don't know how to (unless I create a fake Watch variable).

Are you referring to the Registers scope under the Variables view?

That's provided by the C/C++ extension, not the Embedded Tools extension, but it does track the current frame (see microsoft/MIEngine#1039).

[haneefdm]

@aleun Sorry for the misunderstanding.

We have our own debug adapter -- very much like the MIEngine. It did not have a 'readMemory' request until yesterday. The biggest difference between our extension/adapter and cpptools+MIEngine is built-in support for many gdb-servers (for example we know how to start the gdb-server automatically, how to avoid contention with TCP ports, multiple probes, how to reset and program the device, support for SWO/RTT tracing, etc.). Some gdb-servers and their setup can be complicated which we tried to simplify.

Another misunderstanding. I saw the registers-webview/index.html (in the installed extension) and wrongly thought that it was for the MCU registers. It is actually the view of peripherals (via SVD file). It is called 'Embedded Registers' in this blog. We called it 'Cortex Peripherals' in our extension.

We had a separate 'Cortex Registers' Panel but it was not reflective of the currently selected frame. Yes, we eventually did the same as MIEngine. It is now a scope.

Anyway, my hope was for users using our extension Cortex-Debug to be able to use this extension. This is what the OP @stanczyk4 was asking for and I thought it was a great idea..

I can make any changes needed in our extension quickly. I can submit PRs for anything in your source as well (should be very little) but I see that source is not available. We did not implement the whole DAP and sometimes we used custom requests until things become official in the DAP. Yes, I was involved in adding the memory requests and the disassembly requests to the DAP.

[benmcmorran]

Thanks for the clarification @haneefdm, and sorry about the delay. That all makes sense to me. I can do some experimentation with the Cortex-Debug extension and let you know if there are any changes needed to Cortex-Debug itself to work with Embedded Tools. As you mentioned, I expect that any required changes will be small.

[haneefdm]

I will also try to use cpptools/cppdbg and see if it works with our RTOS viewer. It should!! It will also tell me if anything needs to change. WHen everything works, then there is not a problem. It is when we get errors from gdb, we could be behaving differently and client may be seeing things differently. I released my own RTOS viewer in the meantime...

https://github.com/Marus/cortex-debug/blob/master/CHANGELOG.md#v141

Our RTOS viewer is 99% independent of our own DAP (I commented out support for cppdbg). What I want to do is to provide a Usesr setting for a set of debuggers we should be watching for in our Debug tracker. Perhaps that method can also work for you and that way if someone else comes along, they would be able to take advantage of that as well.

[hongshui3000]

Support for cortex debug still doesn't seem to be working, any plans?

[benmcmorran]

Embedded Tools pre-release version v0.1.220712002 and later include support for Cortex-Debug. This build is available on the pre-release channel in the VS Code marketplace.

A recent build of Cortex-Debug that includes this commit is required, which as of today means you'll need to build Cortex-Debug from source. If everything looks good, we'll promote the fix to an official (not pre-release) version soon.

[hongshui3000]

In my case, It's already working

[haneefdm]

We just did the reverse. Cortex-Debug RTOS views will now work with cppdbg. This is available in our pre-release 1.5.4. And thanks to @benmcmorran, memory views now work in Variable/Watch windows as he did a PR#164 of cortex-debug

FreeRTOS is the one RTOS supported by both extensions. I tested it using this and the RTOS views worked in both extensions simultaneously.

@robotdad @gcampbell FYI

Perhaps we close this issue and deal with any issues that arise later. Note: I did not submit this Issue/Request.

[haneefdm]

With the latest pre-release (1.5.5), you can also enable viewing the Peripheral View provided by this extension while using Cortex-Debug for debugging. The launch.json property svdPath enables this extension's peripherals view -- this is the same as what you would do for cppdbg.

Zero code changes were needed for Cortex-Debug. Just an update to documentation and package.json