[support]

Sorry about that, it’s a known limitation of ST-Link. This happens because one ST-Link tries to execute a single instruction when stepping over the code, an interrupt arrives and your board starts handling it.

As a workaround, please consider setting the $primask register to 1 via the Watch window during stepping.

This will temporarily disable interrupts. Please do not forget to set it back to 0 once you are done stepping, as otherwise the interrupts won’t be re-enabled.

[support]

Hi,

Sorry, the log you attached was the build log, not debug log. Please follow the instructions described here to capture a debug log.

[support]

Hi,

Just wanted to let you know that instead of hardcoding the library paths, we would recommend adding “=/opt/vc/lib” to the “library search path” field.

Regarding the project conversion, the easiest way to do that is to add another configuration and copy the settings there. As switching large projects between direct and cross-build looks like a relatively rare scenario, we don’t want to add a specific fully-automatic command for it. That said, if we get more requests for this feature, we will reconsider this.

[support]

Hi,

Normally the reference to the imported hardware register file should be saved to the <mcu>.xml file in your project directory (see the EmbeddedProfileFile element in the .vgdbsettings file).

Please ensure that this file exists and is writable.

[support]

Hi,

OpenOCD is the recommended debug method for embedded targets, so it should normally work.

Please try enabling GDB logging via VisualGDB Project Properties -> Advanced GDB Settings and post the full gdb log along with the OpenOCD output here. It should explain what is going on and why the target is not resumed.

[support]

Hi,

VisualGDB takes the RAM/FLASH size values from the bsp.xml file in the BSP directory. It is hard to say why they could be wrong without knowing the MCU type.

Please let us know which MCU you are using and what are expected/observed values and we will investigate this.

[support]

Hi,

We will try to address it in v5.3. We expect the first preview build of v5.3 to be released in the next month, although we cannot guarantee that this fix will be included early in the release cycle.

[support]

Hi,

Yes, it will be included in v5.2R9.

In the meanwhile you can download the latest daily build here: http://sysprogs.com/files/tmp/VisualGDB-5.2.15.1423.msi

[support]

Hi,

VisualGDB Python support is mostly targeting the cases when you want to debug Python <=> C/C++ integration issues. If you are debugging Python-only code, other products (not dependent on GDB) would simply provide faster and smoother experience. You can still use VisualGDB for python-only debugging, but this is not our primary use case and VisualGDB is not optimized to handle it in the best possible way (that would require a completely different debugging technology not related to VisualGDB).

Hence if you are looking for Python-only debugging, we would advise checking Python-specific products and IDEs.

[support]

Hi,

The UsbDriverTool is actually included in our OpenOCD package and can be launched using the “Start driver tool” link shown if you switch OpenOCD to custom mode.

Regarding the documentation, we usually try to organize it in the format of tutorials, but if you believe a user-edited wiki could be more helpful, we could certainly host it.

[support]

Please try enabling the verbose mode for the linker (add -Wl,-verbose to the LDFLAGS) to see a detailed log on the paths checked by the linker when it attempts to locate those files. This should explain why they are not found.

[support]

Hi,

Our STM32 package was last time updated in December 2016, so it does not include the latest package from Feb 17. We are currently building the new STM32 BSP and expect to release it in the next 2-3 weeks, so if you don’t want to go through resolving the import issues yourself, we would recommend simply waiting until we fully support it.

[support]

Hi,

This is a known limitation. OpenOCD requires the WinUSB-based driver, while Segger J-Link software uses their own proprietary driver.

This can be fixed permanently if Segger either shares their driver specification with the OpenOCD community (and someone adds support for this to OpenOCD), or J-Link software itself is modified to recognize the WinUSB driver. Both options are fairly complex, so we would not expect either of them to become available in the near future.

That said, you can switch the driver back very easily. Simply run UsbDriverTool by clicking the corresponding link in OpenOCD Settings -> Manual mode, right-click on Segger J-Link and select “restore default driver”.

[support]

Hi,

This could be an indication of a wiring problem, so errors can occur intermittently and it may appear that one IDE works, while a different IDE with slightly different timings does not. Please double-check your board connections.

Another reason for this could be that your firmware is disabling the JTAG unit. Please try modifying the OpenOCD scripts as shown in this tutorial to enable the “connect under reset” mode.

[support]

In order to understand what is going on, please use the Call Stack window to locate the code that calls the syscall function.

If the syscall is used to report a critical error, please try tracking back what causes the error.

[Author]

Posts