[support]

Sorry, this is something to check with Segger support. We are not affiliated with Segger and do not have any insights into their tools’ internals.

[support]

Thanks for pointing this out. Indeed the latest release of TinyEmbeddedTest added a new option that would require rebuilding the settings.

We have fixed the issue in the our development branch (VisualGDB-5.5.2.3450.msi). It will automatically pick default values for the new settings if they are not specified.

[support]

No problem, you can specify the key via registry:

HKEY_CURRENT_USER\Software\Sysprogs\VisualGDB\Settings\RegistrationKey

[support]

No problem. Most likely, the chip you are using handles the exceptions slightly differently from the way OpenOCD would expect them and hence prevents the breakpoints from being handled correctly. Normally, this should be fixed in one of the upcoming OpenOCD updates.

Either way, if J-Link software works better, you can use the following workaround to avoid the “Attach to crashed/frozen target”. Try creating a gdb script with the following contents:

target remote :2331
monitor go
disconnect
quit

It instructs gdb to connect to the J-Link gdb stub, resume the target and disconnect. You can run it via command line as shown below:

<VisualKernel directory>\KernelTools\arm\arm-linux-gnu-gdb.exe -s <script file>

Or alternatively, add it to VisualKernel Project Properties -> Custom Debug Steps -> Before Debugging. This will allow VisualKernel to connect to the target via SSH and handle deployment/module enumeration as if it does with regular debug sessions.

[support]

Thanks for sharing this. If the K210 OpenOCD does not support reading the peripheral registers, it might be worthwhile checking whether Segger J-Link supports it. J-Link comes with its own gdb stub that works better than OpenOCD in many non-trivial scenarios. VisualGDB supports working on top of either debug method, so if J-Link supports the K210 hardware registers, you should be able to switch very easily.

[support]

Thanks for the update. It indeed looks like OpenOCD reads incorrect values. Please try reproducing the problem using the OpenOCD and gdb binaries shipped by Kendryte (OpenOCD installed by VisualGDB is built from the same sources, but there’s a tiny chance that the original Kendryte build would work differently). If you can also reproduce the issue with the original Kendryte tools, please forward this to Kendryte support. If the original tools work as expected, while VisualGDB doesn’t, please let us know and we will help you configure VisualGDB to replicate the results you get with command-line tools.

[support]

No problem. If reading the memory using the GDB commands also results in invalid values, we would advise double-checking the addresses. E.g. try adding the following code to your program:

volatile int test = *((int *)0x<address>);
test = test;

Then evaluate the ‘test’ in the debugger (or print it to a COM port programmatically). If the value is still -1, the address you are using is likely incorrect, or the peripheral clock has not been enabled.

If the ‘test’ variable shows a correct value and reading the memory via GDB at the same time shows -1, it might be a bug in the Kendryte’s port of OpenOCD. If this is the case, please consider checking with Kendryte whether there is a fix for this.

[support]

Hi,

VisualGDB uses the regular memory reading API of the underlying debug method in order to read the peripheral register values. Hence, you can easily verify whether this mechanism is working correctly by running the following commands in the GDB Session window:

x/1x 0x<address of a register>
monitor mdw <address>

The first command requests the memory contents from the gdb debugger, while the second one is forwarded to OpenOCD (low-level tool for interfacing with the JTAG adapter).

Please let us know if using the commands shown above still results in incorrect values and we will suggest further diagnostic steps.

[support]

Hi,

Sorry, in order to troubleshoot a specific project that doesn’t come from us, we would need to charge a consulting fee, as it takes non-trivial time to go through all the settings and source code and find the exact cause of the problem. If you would like to go ahead, please contact our sales to get a quote.

An alternative would be to create a new project from scratch and then move your existing code to it step-by-step, verifying that the additional memory loading works after each step (consider creating a local git repository and checking in the changes after each step to track them better). This would require some time, but should help you find the root cause of the problem on your side.

[support]

Hi,

Please try running VisualGDB.exe /about from the same user account you use for Jenkins in order to show the “About VisualGDB” window that allows entering the registration key.

[support]

Hi,

It looks like your support period has expired. Please renew it here and we will be happy to help you.

[support]

Hi,

For most of the targets (including ESP32), the built-in gdb simulator is not sufficient to run any meaningful code and can only be used to test that gdb can load the image and parse the symbols. Generally, we would advise getting one of the boards supported by VisualGDB (see our ESP32 tutorials).

[support]

This is the same issue the “Warn : Cannot identify target as a STM32 family.” error means that OpenOCD does not know the FLASH configuration for this device (i.e. does not support it).

[support]

Hi,

Thanks for pointing this out. Indeed our latest STM32 BSP didn’t work with the non-GNU version of C99. We have fixed it and updated the package. Please try reinstalling it via Tools->VisualGDB->Manage VisualGDB Packages (or alternatively change the C standard to C99 with GNU Extensions).

[support]

Just wanted to give a quick heads up that if you are looking for community help, please also consider asking on StackOverflow. It has a large developer community, including many STM32 users and some of them might have encountered a similar issue before.

[Author]

Posts