[support]

Hi,

This looks just fine. The program has been uploaded and started.  The errors shown by OpenOCD should not prevent it from working.

You can double-check it by setting a breakpoint inside loop() – it should trigger soon after the program has started.

That said, please make sure that you do not modify the original sample code in any way until you confirm that you can debug it. Changing some parameters (e.g. controlling JTAG pins directly) would indeed stop debugging from working.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch. See this page for more information and detailed examples.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

[support]

OK, we have looked into the way RTX manages its objects and it turns out it flags them in a special way inside the heap, so that the debugger can walk the heap blocks, determine the object types, and display their state.

We have updated our RTX plugin to show the following object types:

• Threads
• Timers
• Event Flags
• Mutexes
• Semaphores
• Memory Pools
• Messages
• Message Queues

The objects can be viewed via the RTX Objects view in Live Variables window:

As the RTX objects have many different fields and modes, we have made the layout customizable via an XML file. If you would like to pull some extra fields from the objects to the top-level view (above the [raw object] node), you can simply add the PromotedFields elements to it.

Please try the following build, it contains the updated plugin and the necessary interfaces: VisualGDB-5.6.109.4827.msi

Let us know if you have any further suggestions or encounter any issues. If you end up customizing the view by editing RTOSObjectTypes.xml, feel free to share your changes, and we will be happy to merge them on our side.

Attachments:

You must be logged in to view attached files.

[support]

Sorry about that. The new build came from our development branch that was recently updated to support the new built-in ARMClang assembler, and it looks like it was adding armclang-specific flags to the legacy armasm executable. We have fixed it in the following build: VisualGDB-5.6.109.4826.msi

[support]

Thanks, we have reproduced and fixed the problem. Indeed, the Keil compiler was reporting the array size in a slightly different format from the one expected by VisualGDB. Please try this build: VisualGDB-5.6.109.4825.msi

[support]

Hi,

Thanks for renewing your license.

This error happens because VisualGDB tries to use the shell executable on the target in order to pass some additional environment variables to gdb. The executable is likely broken, or named in an unexpected way, and this triggers the problem.

You can find out the exact command line used by VisualGDB via View->Other Windows->VisualGDB Diagnostics Console (you need to enable it, then reproduce the problem, then check the output for the full command line mentioning the gdb executable).

Once you find out the command line, please try running it manually via an SSH client, and ensure that you get the same error message. If you could share the exact command line you extracted, and more details about your system (e.g. the correct path of the tool referenced in the command line), we can help you configure VisualGDB to adjust it accordingly.

[support]

Hi,

The contents of the Live Watch window is derived from the DWARF debugging symbols inside the ELF file produced by the compiler. It could be that for some data layouts the array size is recorded in an unsupported way, or is reported to be 1.

The easiest way to track the root cause would be to create a new project from scratch, copy the minimal repro code there, verify that the problem still persists, and then attach:

1. The source file or the code snippet
2. The exact ELF file used for debugging (typically ProjectName.elf or ProjectName without extension)

You can also have a quick peek into the debugging symbols by running arm-none-eabi-objdump.exe -g <ELF file> (objdump is a part of the GCC for ARM toolchain and will also work with Keil executables). If the array definition does not mention the size, or the size is 1, VisualGDB would not have sufficient information to display the entire array.

[support]

No problem, we will clarify.

VisualGDB has 3 different levels of RTOS integration via open-source plugins:

1. Just displaying the threads in the regular Threads window. This is currently supported for FreeRTOS, RTX, ThreadX and Zephyr (NRFConnect devices only).
2. Automatic detection of thread switches in the profiler/real-time watch. This is supported for FreeRTOS and RTX.
3. Non-intrusive real-time view of various RTOS primitives as shown in this tutorial. This is only supported for FreeRTOS.

If you would like to get the 3rd option to work with RTX, the RTX plugin would need to be extended to implement the Live Watch interfaces similar to the FreeRTOS one. As your company holds a substantial amount of active VisualGDB licenses, we should be able to do most of it for you. Feel free to reach out to our support with more details (your device type, the exact RTX version and the types of RTOS objects you would like to view) and we will get back to you with a time frame.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch. See this page for more information and detailed examples.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

[support]

Hi,

We are not aware of any known issues that would be causing it. One other customer mentioned that a recent update of a debugging tool (they didn’t specify which one) broke the logic for setting the initial stack pointer, so instead of pointing to the end of RAM, it would point to a random location. That said, we were never able to reproduce it on our side.

Either way, you can easily narrow it down by following the steps below:

1. Enable GDB logging.
2. Run a debugging session and ensure it crashes.
3. Locate the following lines in the log file:
   • target  remote :<port>
   • load
   • continue
   • any commands starting with ‘mon’ or ‘monitor’ that are forwarded straight to the GDB stub
4. Try running OpenOCD or J-Link manually, then run gdb manually and execute the same commands.
5. If the crash persists, try running “mon reset” (J-Link) or “mon reset halt” (OpenOCD) after the “load” command.
6. If it solves the problem, please try checking the value of sp (print (void *)$sp) before and after the ‘load’ command.

If you can confirm that running “load” with J-Link breaks the value of $sp, please feel free to report it to Segger support. They should be able to fix it on their side.

If the issue is caused by something else, you can use the “reset device after programming” checkbox in VisualGDB Project Properties -> Debug Settings. It will automatically insert the reset command after the load command. You can also customize the exact commands VisualGDB sends to gdb via the Advanced view on the same page.

[support]

No worries, it looked like a great feature to add.

We’ve added the tag display in the selected interface field to the following build, feel free to try it out: VisualGDB-5.6.109.4823.msi

[support]

Hi,

You can try fully closing the window and reopening it. That said, we recently updated the column resizing logic to only apply once the mouse button is released. It should help avoid the original problem in the first place. Feel free to try this build: VisualGDB-5.6.109.4822.msi.

[support]

Hi,

The Debug->Windows->RTOS Objects view is likely provided by another extension. VisualGDB reports the RTOS threads via the regular thread interface, so they can be viewed via Debug->Windows->Threads.

[support]

OK, we have added support for debug interface tags to this build: VisualGDB-5.6.109.4816.msi. You can now click the tag icon next to the serial number and VisualGDB will allow entering an arbitrary tag that will be associated with this specific device and always displayed in the list:

Attachments:

You must be logged in to view attached files.

[support]

Thanks, this indeed looks like a bug in the logic that prevents the incompatible armclang options from being passed to armasm. We have fixed it in the following build: VisualGDB-5.6.109.4816.msi.

You can also apply the patch on your side without reinstalling VisualGDB by locating the following statement in the %VISUALGDB_DIR%\MSBuild\Targets\gcc.targets file:

<ItemGroup Condition="'$(GNUToolchainSubtype)' == 'armclang'">
	<ClCompile Condition="'%(ClCompile.IsAssemblyFile)' == 'true'">
		<AdditionalOptions/>
	</ClCompile>
</ItemGroup>

Then, you would need to change the <AdditionalOptions/> line to this:

<AdditionalOptions>$(ARMASMArguments)</AdditionalOptions>

 

[Author]

Posts