[support]

Hi,

Thanks for letting us know. If you encounter further errors, feel free to create another topic.

[support]

Hi,

Please try adding the .natvis file directly to your VS project (via right-click->Add->Existing Item). This should help VisualGDB recognize it.

[support]

Hi,

The .bin file generated by VisualGDB should be the correct one. Furthermore, once you start a debugging session, the firmware is actually programmed into the FLASH memory in order to be debugged.

Most likely your code is using semihosting-related functionality (e.g. calling printf()) that are intercepted under debugger and cause the program to wait for a debugger to attach otherwise. The easiest way to figure out what is going on is to use the Debug->Attach to Running Embedded Firmware command (requires VisualGDB 5.3+).

[support]

Hi,

Looks like your program is missing the ‘airkiss_lan_pack’ function that is normally defined in libairkiss.a. Please try adding “airkiss” to the “library names” field in VisualGDB Project Properties.

[support]

Hi,

Please use the via Debug->Windows->Registers command to view the CPU registers.

[support]

Hi,

Sorry, as we don’t have an STM32l443RC  board here, we would be able to reproduce it/confirm the fix, hence we won’t be reporting this to OpenOCD.

Please consider reporting this via OpenOCD mailing lists as described here: http://openocd.org/doc-release/doxygen/bugs.html

Please also try our latest update to the OpenOCD package. It may already include the fix.

[support]

Hi,

You might be missing extern “C” around your interrupt handler. Please also note that our support is limited to issues related to VisualGDB. For general programming problems and troubleshooting issues with your code please use other resources like StackOverflow to get help from other community members.

[support]

Hi,

Thanks for reporting this. It looks like an OpenOCD bug, so we usually rely on the OpenOCD community to fix those.

As a workaround please try adding command to erase FLASH in to the additional gdb commands in VisualGDB Project Properties.

E.g.:

mon flash erase_sector …

You can find more about OpenOCD FLASH-related commands here: http://openocd.org/doc/html/Flash-Commands.html

[support]

Hi,

Sorry, the logs you attached unfortunately don’t show any timing. You can enable generation of timestamped logs via VisualGDB Project Properties -> Advanced GDB Settings -> Save all low-level interaction with GDB.

Please also try using this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.14.1892.msi

It resolves another issue related to Segger GDB stub and might solve the performance issues you are encountering as well.

[support]

Hi,

Thanks, looks like the ‘connect under reset’ indeed doesn’t work on STM32F7. We have fixed this in the upcoming update to the OpenOCD package.

As a workaround, please try changing the following line in stm32f7x.cfg:

reset_config srst_only srst_nogate

replace it with the version from F4X:

reset_config srst_nogate

Then VisualGDB will recognize it and show the “connect under reset” option.

[support]

Hi,

Sorry for the confusion. Changing the location of the main memory to SDRAM would not work as your firmware would need to use the memory for the stack before it can initialize the SDRAM controller.

If you want to make the malloc()/free() functions use SDRAM instead of the regular SRAM, please add an implementation of the _sbrk() function similar to the one described in this tutorial: https://visualgdb.com/tutorials/arm/newlib-nano/

Instead of returning the area between the _end symbol and the stack pointer, change the implementation so that it will return the memory between the start and end of SDRAM.

[support]

Hi,

It looks like your trial has expired. In order to keep on receiving technical support please purchase a license. If you have already purchased a license under a different email, please let us know and we will update our records.

Please also note that the VisualGDB support covers issues that are related to VisualGDB (e.g. functionality that is broken when using VisualGDB, but works otherwise). If the ESP8266 SDK is missing examples/documentation on certain scenarios, please ask on the ESP8266 forums instead.

• This reply was modified 7 years, 8 months ago by support.

[support]

Hi,

We actually have a detailed tutorial showing this: https://visualgdb.com/tutorials/arm/memories/

Feel free to follow it and let us know if you have any questions.

[support]

Hi,

We actually removed the direct mode as it was causing race conditions inside the J-Link DLL and sometimes showing incorrect data. It should normally not affect the normal debugging speed, only the speed of the real-time watch. Can you confirm that all debugging is now slow? Would you be able to share the gdb log with the timing labels so that we could see if we can work around this?

[support]

Hi,

We understand you didn’t change anything, however sometimes the problems are caused by unexpected combinations of small changes or incompatible settings that are hard to predict. We advise following the diagnostic steps in the previous post to resolve this.

[Author]

Posts