[support]

Hi,

Please check the contents of the OpenOCD window for more specific error messages. This should explain why FLASH programming fails.

[support]

Hi,

Looks like the address sanitizer is not supported your platform. Please note that it does not work on barebone embedded targets.

[support]

Hi,

The final release would be this summer. Currently we are focusing on updating support for devices and frameworks and we will be introducing another product for embedded software developers in the next few weeks. You can get a feed of our updates on our Twitter page: https://twitter.com/Sysprogs/

[support]

Hi,

Do you mean a static library? You can do that by selecting “static library” in the wizard or changing the output type to “static library” via Visual Studio Project Properties.

[support]

Hi,

Thanks for the screenshot. The behavior you are describing happens because the library files like stm32f0xx.h are located outside the project directory and are shared between all of your projects. Visual Studio’s ‘show all files’ view is based on the physical location of the files and hence shows them flat.

One workaround would be to convert the project to a stand-alone one via the first page of VisualGDB Project Properties. This will copy all the STM32-specific files to a subdirectory inside the project directory and the ‘show all files’ should show them accordingly.

[support]

Hi,

Yes, please check that the HAL_SAI_MODULE_ENABLED macro is defined in the stm32f7xx_hal_conf file.

[support]

Hi,

We don’t fully support nRF5x mbed targets as they require some extra steps and don’t build out-of-the-box. As a workaround please consider using the regular non-mbed SDK for nRF5x for now.

[support]

Hi,

No problem. Based on your description, this could be caused by one of the following:

• The functions are not instrumented properly
• The call time information is not properly received by VisualGDB
• Your chip does not support tracing instruction times

You can do a quick check whether the instruction cycle counter works by running the following code from main():

#define DWT_CYCCNT (*((unsigned *)0xE0001004))
#define DWT_CTRL (*((unsigned *)0xE0001000))
#define COREDEBUG_DEMCR (*((unsigned *)0xe000edfc))

COREDEBUG_DEMCR |= 0x01000000;
DWT_CTRL = 1;
DWT_CYCCNT = 0;
asm(“nop”);
int result = DWT_CYCCNT;

If result is 0, your CPU does not support the instruction cycle counter and the profiler framework will need a minor adjustment to run on that CPU (we can provide details).

If it works, please check if the custom real-time watch events work. If yes, the problem is related to function instrumentation.

Please let us know your findings so that we can help you further.

[support]

Hi,

No problem, we have released the new toolchain: http://gnutoolchains.com/beaglebone/

[support]

Hi,

Thanks for reporting this, we have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1366.msi

[support]

Hi,

First of all, please note that ESP8266 and ESP32 debugging is extremely unreliable and random errors are very common.

We will try to clarify what is going on based on your description. The LIBUSB_ERROR_NOT_SUPPORTED error can actually be safely ignored. OpenOCD shows it as it first tries to connect to the ‘Virtual COM port’ part of the Olimex JTAG probe. If you get your breakpoint to hit, the problem is most likely not related to drivers or JTAG connections, but is caused by one of the tool limitations. We will try to outline them below.

The ESP8266 chip has undocumented watchdog mechanisms that can break debugging if the chip is stopped at a breakpoint for too long. Our OpenOCD port disables the known watchdog, but sometimes the chip still goes to an undebuggable state.

The chip also has only one hardware breakpoint, so you cannot set more than 1 breakpoint in FLASH code. Furthermore, when you step through the code with F10 or F11, gdb internally uses an extra breakpoint, so in order for that to work reliably, you need to remove all other FLASH breakpoints. We usually recommend moving the functions you want to debug to RAM.

Another problem is that the ESP8266 chip sometimes enters some undocumented state where it does not respond to debug requests via JTAG. This happens when using the AT command firmware, but may happen with other functions as well.

Our general recommendation would be to understand what debugging functionality works (e.g. setting breakpoints only in RAM) and rely on it to debug.

[support]

Hi,

This looks like a conflict between files generated by VisualGDB wizard and the files imported from CubeMX.

The ‘multiple definition’ error can be resolved very easily by unchecking the ‘default system file’ checkbox on the Embedded Frameworks page of VisualGDB Project Properties.

The ‘external dependencies’ list is derived by Visual Studio by trying to locate included headers, so it can be incorrect, but this should not affect compilation or IntelliSense.

[support]

Hi,

Sorry about that. We’ll keep a track of this and if we get more similar feedback, we will add a simple key-value based view as well.

[support]

Hi,

It’s hard to promise anything definitive currently, but we will be adding some sort of Clang-powered code analysis in one of the next major VisualGDB releases.

[support]

Hi,

Thanks, we have managed to reproduce and fix this. We have updated the code example in the post above and will ship the correct code in the next STM32 BSP.

[Author]

Posts