Getting thread execution timing for Keil RTX5

[murrellr]

I’m trying to create a real-time thread execution timeline of a device that uses Keil RTX5 as the OS.  I tried setting up Software Tracing but enabling relocation records cause the ARM Clang linker to crash.  This is a known bug in the linker involving the use of a scatter file (Internal fault: [0xb3b91b:6130008]).  I tried many different fixes but none of them worked.  So I’ve given up this path and am trying to fall back to the Embedded Framework Fast Semihosting and Embedded Profiler.  I have selected Keil RTX for RTOS support.  This is actually support for RTX4, but I’m following the workaround for RTX5 given in this tutorial  https://visualgdb.com/tutorials/arm/keil/rtx/tracing/ .  Under Dynamic Analysis, I have selected only Allow tracing various RTOS events in Real-time Watch.  This compiles OK.  When I start debugging, I get this error: “Could not detect the end of FLASH.  Please define it explicitly on the Dynamic Analysis page.”  There is no field on the Dynamic Analysis page to enter the end of flash.

How do I get Dynamic Analysis to work in this case?

• This topic was modified 2 weeks, 6 days ago by murrellr.

[support]

Hi,

Sorry about the confusion. The GUI for setting the end-of-FLASH is hidden unless you enable the instrumenting of functions on the Dynamic Analysis page (see attached screenshot).

As for the tracing, the dynamic tracepoints use fairly complex logic to patch the code after it got already compiled, so indeed, they rely on some advanced compiler features. The good news is that we are working on the GUI for managing coded tracepoints, like TRACEPOINT(“value=%d”, ADCState.Value). These won’t require any special compiler features, and will be integrated into the recording/replaying/configuration GUI, so setting and removing them will be as easy as with regular breakpoints. They will first come out as a part of CodeVROOM (our stand-alone IDE compatible with a subset of VisualGDB), so you will be able to try them out, while still using the stable release build of VisualGDB for the rest of the workflows. We can post a link here in a few weeks, if you are interested in trying them out.

Attachments:

You must be logged in to view attached files.

[murrellr]

Enabling Instrumenting of Functions forces enabling of relocation records.  Is there any way to get this to work without relocation records?

[support]

Sure, you can try enabling function tracing, setting the FLASH size via settings, and then disabling function tracing. Another option would be to just manually roll back the relocation record option after changing the Dynamic Analysis settings. The debugging settings are stored in the .vgdbsettings/.vgdbcmake files, while the linker flags (like relocation records) are stored in the CMakeLists.txt/.vcxproj files.

[murrellr]

I have a Catch-22 situation here.  The UI won’t show until I have built the project with relocation records enabled, but the project won’t build with the relocation records enabled.

Is there any way to manually edit the files to set the endo of FLASH?

[support]

Sure, the .vgdbsettings file has a straight-forward XML structure, so it should be trivial to patch it manually. However, the exact XML element to change would be different for different scenarios.

The easiest way to get it right would be to create a similar project using GCC, make a backup of the .vgdbsettings file, change the settings manually, and diff it against the previous version.

[murrellr]

When I use GCC, there are no embedded frameworks to select.

Going back to Software Tracing, I found if I use a n existing variable buffer, I do not need to enable relocation records.  The program builds an I can create a tracepoint, but when I try debugging I get this error: System.Exception: No section covers 0x603988544

[support]

Hi,

This is possibly happening because the trace buffer variable is not inside a pre-initialized data section (e.g. .data, not .bss). See this page  (search for “pre-defined”) for an example.

With GCC, you can try creating a new project using our BSP (not STM32CubeMX or any other external generator). This way the frameworks GUI should work the same way.

[murrellr]

This is from the map file created by the ARM Clang compiler:

0x24002240 0x00002000 Data RW 2262 .data.trace_buffer platform.o

This is how I declared it:

char trace_buffer[8192] __attribute__((used)) = { 1, };

The page you referenced is out-of-date and the images do not match the screen.

 

[support]

This should normally work just fine. If this is a big project that is already triggering internal linker errors, it could be that something else about it is producing an unexpected memory layout.

If you could share the ELF file, we can try loading it on our side to see why it’s triggering this error.

With screenshots, there should not be any major changes in the GUI since the documentation page was created. Feel free to attach a screenshot of the mismatching GUI, and we can check.

[murrellr]

I changed the variable declaration to this:

char trace_buffer[8192] __attribute__((section(“.data”))) __attribute__((used)) = { 1, };

Now I get a Hard Fault on code startup processing the scatter file.  I have attached an image of the Software Tracing screen.

I can’t give you the ELF file as it is proprietary data of my company.

I have spent way too much time on getting this to work and will likely develop my own solution.

Attachments:

You must be logged in to view attached files.

[Author]

Posts