[support]

Hi,

No problem. We have just released the Preview 2 that supports Peek Definition and has improved performance. You can download it here: http://visualgdb.com/download/

[support]

Hi,

This should be already fixed in VisualGDB 5.3 Preview 1. Please try updating to it.

[support]

Hi,

We have investigated this further and it looks like the mechanism responsible for showing CodeMap-like diagrams has been removed from VS2017 community (still works with VS2017 Enterprise).

You can find more details here: https://developercommunity.visualstudio.com/content/problem/41410/generate-graph-of-include-files-still-not-working.html (the Generate Graph of Include Files command uses the same mechanism).

[support]

Hi,

Most likely you would need to set the “optimize” attribute on some of the inline functions in the kernel headers. Please check the build log for the actual function that calls __smp_store_release(), e.g.:

1><...>\include\asm-generic\qrwlock.h(165,2): note :  in expansion of macro `smp_store_release'

E.g. with kernel 4.10 you would need to set the optimization for the queued_write_unlock() function:

static inline void queued_write_unlock(struct qrwlock *lock)
{
    smp_store_release(__qrwlock_write_byte(lock), 0);
}

[support]

Hi,

Strange. The first step for diagnosing this would be to understand which component causes this message. Do you get it in the “GDBServer” window in Visual Studio, or elsewhere? If you are not sure, please simply attach a screenshot.

[support]

Hi,

Thanks for the screenshot and sorry about the confusion. This could happen if you were not right-clicking on a globally visible entity (like a function) that could be shown in a code map.

Please try first left-clicking on the function name, then ensure that it appears in the rightmost combo box on the smart navigation bar and finally right-click again. Does the code map menu appear?

[support]

Hi,

You could try using the _sbrk() implementation that comes from our “Fixed-size stack and heap” framework described in this tutorial: https://visualgdb.com/tutorials/arm/stack/

You would need to modify the linker script to place the “.heap” section into SDRAM and explicitly set the heap size via VisualGDB Project Properties.

[support]

Sorry, the screenshot did not get uploaded properly. Could you please upload it to an image sharing hosting? I.e. a screenshot showing the context menu when you right-click on a function like “main”.

[support]

Hi,

Good to know it works. BTW, we have added support for the “Peek definition” feature to the Clang IntelliSense in the upcoming VisualGDB 5.2 Preview 2, and also significantly improved performance and added a special mode for diagnosing parsing time. If this sounds like something worth giving a try, let us know and we can share a build with this feature.

[support]

Hi,

This could be caused by either X11 forwarding or the gdb signal handling. Please try configuring VisualGDB to display the X11 windows on the Raspberry Pi itself instead of forwarding them to your Windows machine. If this does not help, please check if you can reproduce the same behavior with a basic program that will not have any other code besides the waitKey() call.

[support]

Hi,

We usually only officially support major releases of the ESP-IDF, as the in-between versions that introduce new functionality often also break old features.

As the ESP-IDF is being developed very rapidly, we have actually added support for importing projects built directly by esp-idf that does not require an updated BSP from us.

I.e. you can simply replace the contents of the esp-idf.orig directory with the latest version of ESP-IDF and follow this tutorial: https://visualgdb.com/tutorials/esp32/esp-idf/

[support]

Hi,

The problem with treating the mbed-cli projects as normal editable VisualGDB projects is that it would depend on the internal format of the files generated by mbed-cli and will stop working each time the format changes.

So with mbed we essentially offer 2 approaches:

• Using our BSP that is verified, tested and maps common mbed features to easily editable embedded frameworks. But it’s updated quarterly as we need to manually keep up with the changes to mbed itself.
• Manually importing an mbed-cli project. This is less intuitive and requires some extra steps, but will still give you access to advanced debug and IntelliSense features and does not force you to use a specific mbed version.

[support]

Hi,

This actually looks like a bug in our STM32 BSP. Please try locating the following lines in the BSP.XML file:

      <AdditionalIncludeDirs>
        <string>$$SYS:BSP_ROOT$$/STM32L1xxxx/STM32L1xx_HAL_Driver/Inc</string>
        <string>$$SYS:BSP_ROOT$$/STM32L1xxxx/STM32L1xx_HAL_Driver/Inc/Legacy</string>
        <string>$$SYS:BSP_ROOT$$/STM32L1xxxx/CMSIS_HAL/Device/ST/STM32L1xx/Include</string>
        <string>$$SYS:BSP_ROOT$$/STM32L1xxxx/CMSIS_HAL/Include</string>
      </AdditionalIncludeDirs>
      <AdditionalPreprocessorMacros>
        <string>$$com.sysprogs.bspoptions.primary_memory$$_layout</string>
        <string>$$com.sysprogs.stm32.hal_device_family$$</string>
        <string>$$com.sysprogs.bspoptions.stm32.hal_legacy$$</string>
      </AdditionalPreprocessorMacros>

Then simply remove the line with $$com.sysprogs.bspoptions.stm32.hal_legacy$$ (ensure that you do it for the L1 definition, not F1 definition).

We will also fix this in the upcoming STM32 BSP refresh.

[support]

It looks like you are trying to debug the system linker application instead of your own application.

Please check the debug page of VisualGDB Project Properties and ensure you debug the $(TargetPath) instead.

[support]

Hi,

The Code Map is a part of our Clang IntelliSense engine and hence will only work if you have it enabled. Please double-check that you are actually using it (you can check this by right-clicking in the source file and checking if the “Preprocess selected lines” command appears).

[Author]

Posts