Visual GDB Packages & FreeRTOS

[Salieri]

Hello, I have a couple of questions:

1. Is there any way to regenerate package files (for example, the FreeRTOS or HAL source files)? I made edits to some files that I wish to undo (I overwrote the original files).
2. Are there any plans to update the FreeRTOS version from 8.2.3 to 9.0.0?
3. Barring that, I would like to use the FreeRTOS v9.0.0 in my project since it has a stack mapping capability for Heap_1 and I desperately need this in order to pair a bootloader with FreeRTOS on a M-0 core that has no VTOR remap capability. Do you have any suggestions as to how can I upgrade the RTOS so that it will work best with VisualGDB?

Bonus question (no need to answer since it’s my problem), but still, perhaps someone will see this:

• Do you have any idea how can I protect the first 192 bytes of RAM from FreeRTOS and stack so that I can put the Interrupt Vector Table there? I can manage to put the Vector Table there and remap the SRAM to 0x0000 0000 but the IVT gets overwritten by the stack/heap.

[support]

Hi,

Please find the answers to your questions below:

1. The FreeRTOS package is normally a part of the BSP for your devices (e.g. STM32). You can reinstall any of those BSPs via Tools->VisualGDB Package Manager.
2. We always ship the FreeRTOS version that is included in the driver packages from ST. Once ST updates their packages to FreeRTOS 9.0.0, we will update our package as well.
3. You can simply remove the reference to the FreeRTOS shipped with VisualGDB and then manually add the files from your FreeRTOS checkout (and the include directories) to the project. This will probably require some minor adjustments (e.g. the configuration file and some macros).

If you want to figure out what is overwriting your IVT, we would recommend using a hardware breakpoint (Debug->Windows->Breakpoints->Add->Data Breakpoint). As soon as the CPU tries to modify the corresponding memory range, it will trigger and you will see the code responsible for it.

[Salieri]

Thank you for your answers. I think I solved the problem by using a custom, unused SRAM sector in a linker file, effectively offseting the symbol addresses for the length of my IVT.

I have a suggestion to offer:

• In the memory view, I’d personally find it useful if you could limit the length of the memory shown. I’m only interested in the first 192 bytes starting from address 0x08100000 and since the window is quite unresponsive, It’s pretty difficult to work with all the neighboring data.

I’m using 5.2 and I checked “use advanced memory view” or something like that.

• This reply was modified 7 years, 4 months ago by Salieri.

[support]

Hi,

Good to know it works.

Regarding the memory window, VisualGDB normally only queries the region of memory that fits in the current window. Reducing the memory window height will reduce the amount of queried data. You can also try switching to the live memory engine (lightning icon in the toolbar) to improve the memory read speed. Also if you are using a VM with USB virtualization, it could significantly reduce debugging performance, so we would recommend moving it to a physical machine.

If you believe the memory window is still slow, please let us know and we will consider optimizing it further.

[Author]

Posts