Support for Azure RTOS

[v_krishnan]

We have created a custom embedded project in VisualGDB for our board, which will be using Azure RTOS. We have manually been able to setup the build process and it is working fine.
Now, we are using Segger J-Link to debug the application on our hardware.  Is there any support for debugging the RTOS threads in VisualGDB or known plans for the same?
How about the other RTOS primitives like mutexes, events, etc.?
Also, is there any mechanism to check the execution state of each core in a multi-core target?

[support]

Hi,

We have recently added out-of-the-box Azure RTOS support to our STM32 BSP (see version 2022.01) and also updated VisualGDB to display AzureRTOS threads.

Please feel free to try this build: VisualGDB-5.6.102.4521.msi. The new functionality will also be available in the upcoming VisualGDB 5.6R3.

The visualization of RTOS primitives (mutexes, events, etc.) is not yet supported, however we will consider adding it in the future based on the popularity of AzureRTOS among our users.

If you are using Segger J-Link, it should normally present each core of a multi-core target as a separate thread, so VisualGDB would display their state out-of-the-box. If not, please let us know and we will investigate it further.

[Sergey Volkov]

Did you see this?

Embedded Software Development in Visual Studio

[support]

Hi,

Visual Studio had basic support for embedded development since about 2018. It is comparable in functionality and usability to free tools like Eclipse and VS Code, however many non-trivial scenarios require lengthy manual setup and considerable ongoing effort to maintain a working environment. The recently added support for Azure RTOS continues the line and makes sense given the prior acquisition of ThreadX by Microsoft.

VisualGDB, on the contrary, focuses on usability, better IntelliSense engine with features like CodeJumps and Code Explorer, and also numerous advanced debugging and code analysis features. Hence, if you are looking for a basic development environment, you may find many free solutions good enough, but if you are considering non-trivial projects that could benefit from advanced tools, VisualGDB offers numerous ways of making your workflow more productive.

[v_krishnan]

Thanks, will give the new build a try.

[v_krishnan]

In an earlier reply to my original question, it was suggested that Segger J-Link should present each core of a multi-core target as a separate thread under VisualGDB. I’m seeing only a single thread. Is there any specific setting or configuration process to enable this?

My target is having two identical A7 cores. So, I want to run my application wherein my RTOS threads can be scheduled on any core, and I should be able to debug them. Is it possible using a single instance of Visual Studio, or do I require to open the same project in separate instances and debug each core separately?
I would ideally prefer a single instance to debug both the cores.

[support]

Hi,

If you are using J-Link, it should automatically report each of the device cores as a separate hardware thread, and VisualGDB should extend this information with the software threads recovered from parsing the RTOS structures.

Could you please try running the “info threads” command in the GDB Session window? Does it show 2 threads or just one? How does it compare to the Debug->Windows->Threads window contents in Visual Studio?

[v_krishnan]

I get the following output from “info threads” command. The “Threads” window also shows a single thread only.

info threads
&"info threads\n"
Id Target Id Frame 
* 1 Thread 57005 cstartup () at startup.s:74
OK

Note: I get three options to choose the target device from, in the debug settings – R9A06G032, R9A06G032_CPU0, R9A06G032_CPU1. I’ve selected the first option.

[support]

Thanks for confirming this. Selecting the first option should normally indeed target both cores. If the second thread does not appear, you might be using an older version of the J-Link gdb stub, or missing some additional parameters.

We would advise double-checking this with Segger support – simply forward them the J-Link gdb stub command line shown in the VisualGDB Output window, along with your device name and the Segger software version, and they should be able to suggest a way to configure the stub to show each core as a separate thread.

[v_krishnan]

I checked it up with Segger. Here’s there response –
<div>SMP debugging is not support by J-Link or J-Link GDB Server at the moment.</div>
<div>SMP debugging is planned for the future but without fixed schedule.

I guess I then have to use OpenOCD compatible debugger to do the SMP debugging, correct? Is IAR ijet supported by VisualGDB?</div>

[support]

Thanks for the update. If the J-Link gdb stub doesn’t support SMP debugging, there is no easy way to make VisualGDB show both cores in the same session when debugging with it. That said, the gdb stub might open a separate GDB port for the second core, so you can use a second Visual Studio instance to debug it in parallel with the first one. If this works for you (and the Segger can confirm that the stub opens a second port, we can help you configure VisualGDB accordingly).

OpenOCD, indeed, would be another option. You would need to follow the steps below:

1. Replace the regular J-Link USB driver with the WinUSB one (VisualGDB can do it for you if you use the USB Devices view).
2. Create an OpenOCD script file that would define both cores and enable the hwthread RTOS on them (hwthread is a dummy RTOS that shows each core as a separate thread). You can also specify ThreadX instead of hwthread to have OpenOCD parse the thread state.
3. Run OpenOCD with interface/jlink.cfg and your target script. OpenOCD will connect to J-Link and will allow debugging your target as usual.

If your device contains a FLASH memory, OpenOCD may not have a driver for it. However, if you are using our OpenOCD fork (installed by VisualGDB by default), you can make use of the FLASH plugin interface to easily create a FLASH programming driver.

Last time we checked, IAR ijet relied on a proprietary undocumented protocol, and hence was not supported by OpenOCD. That said, IAR might provide their own gdb server executable, that would take the place of OpenOCD, or the J-Link gdb server. If this is the case, we can gladly help you configure VisualGDB to work with it.

[Author]

Posts