[support]

Hi,

If you are using the Linker Options->Command Line to specify the libraries anyway, you can simply put -Wl,–whole-archive before the library names and -Wl,–no-whole-archive after them.

That said, the recommended way to reference libraries would be to right-click on the executable project in Solution Explorer and select Add->Reference. This will automatically add the libraries to the linker inputs and will also make sure that the libraries are built before the main application. If it helps, we could add a per-library option that will let VisualGDB automatically wrap its name with the –whole-archive/–no-whole-archive when building the linker command line for the main project.

[support]

No problem, we can add an option for wrapping library references with –whole-archive. Just to double-check, are you using MSBuild and referencing the libraries using the regular References window in VS?

[support]

Hi,

The CMSIS-DAP interface is generally very unreliable and slow, so we would recommend simply using ST-Link or J-Link instead.

You might be able to solve the U-Link issue by analyzing verbose OpenOCD log and patching the OpenOCD scripts, however it may not be practical given that ST-Link and J-Link will very likely just work out-of-the-box.

[support]

Hi,

The <VisualGDB>\ProjectTemplates\Linux folder is still present in VisualGDB 5.4 and 5.5 and the underlying logic has not changed much since v5.1.

The custom project templates are still supported, although only with the classic project types (i.e. not with Arduino, Mbed or ESP-IDF). If you believe the path substitution is not working, please share the exact steps to reproduce the issue and we will advise you on the workaround.

Regarding running custom code, it is not possible to run it during project creation, however it is possible to add it as a custom shortcut (VisualGDB Project Properties -> Custom Shortcuts) that will be available via the Project menu in Visual Studio. You can create a shortcut for the initialization commands that should be run after creating the project from the template and then run it after creating the project from the template.

[support]

Thanks for renewing your support.

If the firmware doesn’t start completely, we would advise checking the following points:

1. Using Embedded Memory Explorer, check that the interrupt vector is present at the correct address (double-check the address in the device datasheet, or compare it with a working file).
2. Double-check that the interrupt vector points to the correct Reset handler function. You can dump the contents of the section containing the interrupt vector by running arm-none-eabi-objdump or do it at runtime by evaluating *((void *)0xADDRESS) via the Watch window.
3. You can configure VisualGDB to stop at the Reset handler via VisualGDB Project Properties – >Embedded Debug Tweaking and then starting debugging with F10 instead of F5.
4. If nothing helps, you can also try hardcoding a breakpoint in the reset handler (asm(“bkpt 255”)) and issuing a manual reset via the GDB Session window (mon reset).

[support]

Hi,

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

[support]

Yes, please refer to the following tutorial for details: https://visualgdb.com/tutorials/arm/semihosting/

[support]

Hi,

Yes, you can configure VisualGDB to extract the memory layout from your custom linker script.

Please try using the latest VisualGDB 5.5 Preview 2, open VisualGDB Project Properties on the Additional Memories page. The setting on top of the page controls whether VisualGDB will use the memory definition shipped with it, or will extract it from the linker script.

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

[Author]

Posts