[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, 12 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.

[support]

Hi,

The executable file normally has no extension (e.g. …/LinuxProject1/VisualGDB/Debug/LinuxProject1). If you are not sure, please try running the “find <project directory>” command via SSH and post the output here and we will help you locate the right file.

[support]

Hi,

Generally in order for a USART to work, you need to ensure the following:

• The peripheral clock for this USART is enabled
• The corresponding pins are configured to work as USART
• You configure the peripheral correctly (e.g. set the baud rate) and write the correct data registers

We have a detailed tutorial showing how to use STM32 UART here: https://visualgdb.com/tutorials/arm/stm32/uart/hal/

Generally we would advise first sorting this out on a regular non-MBED project and then stepping through the mbed source code to ensure that it does the same initialization/configuration steps as your non-mbed project (hardware register window can help double-check that the necessary parts got initialized).

[support]

Hi,

Please use the Help->About VisualGDB window to enter the new key (or re-enter the same key if it was upgraded).

[support]

Hi,

Sorry, this exception is thrown by the VS itself; VisualGDB simply displays it and cancels the wizard. As this is something very rare that should normally not happen, we won’t be adding any special handling for this case. That said, if anyone else encounters this problem, please feel free to update this thread. If it turns out to be not as rare as we assume, we can easily add a check for it.

[support]

Hi,

Please try updating your VisualGDB to v5.3R3 (latest maintenance release) and also update your OpenOCD package via Tools->VisualGDB->Manage VisualGDB Packages.

If you still don’t see the options, please try attaching a screenshot of your Debug Settings page so that we could see which version you are using and suggest a way to update it.

[Author]

Posts