[support]

Hi,

Linker script preprocessing could be related to this. Please try linking the MSBuild project using the preprocessed linker script produced by the mbed-cli build.

If it doesn’t help, you can quickly narrow down the problem by combining command lines from different builds. E.g. try linking the object files produced by mbed-cli with the linker command line from msbuild, and vice versa. If the problem appears to be specific to the linker command line, try gradually changing the broken command line until it matches the working one, rechecking the results after every step.

If the problem is triggered by using the object files from MSBuild, please try replacing half of them with the versions built by mbed-cli, and check if it solves the problem. This should help you quickly find the specific object file triggering the problem.

[support]

Hi,

This looks like a wiring problem. Please double-check your wiring, clocks and power. If nothing works, please contact Kendryte for assistance, as hardware problems are outside of VisualGDB’s control.

[support]

Hi,

Sporadic JTAG errors are typically caused by wiring problems, too fast clocks or unstable power. They are completely outside of VisualGDB’s control, so our best advice would be to try running gdb/openocd manually. If it works better, we can help you configure VisualGDB to match the manual session results. If not, it’s not something VisualGDB could automatically fix.

[support]

Hi,

It looks like you have manually edited some files in the VisualGDB debug packages.

Please try deleting the entire %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages folder and creating another project from scratch, letting VisualGDB download all the packages.

[support]

Hi,

No problem. VisualGDB offers 2 troubleshooting tools to address this type of issue:

• First of all, you can use the Embedded Memory Explorer to compare the build produced by MSBuild against the build produced by mbed-cli. Most likely, it will be missing some symbols, or using different versions of symbols.
• You can also examine the .rsp files produced by MSBuild and compare them against the mbed-cli build logs. This approach does require substantial time, although it allows tracking down every difference between the 2 build setups and getting exactly the same result as the original project. See this tutorial for a detailed example.

[support]

Hi,

Thanks for pointing it out. Indeed, in our test setups, the FreeRTOS.h did not directly include queue.h, so the profiler hooks built without any issues.

We have switched ProfilerRTOS_FreeRTOS.c to reference the FreeRTOS functions in a way that does not depend on the included headers. You can find the details in this commit. The fix will be included in the next update of our profiler framework.

[support]

Hi,

This is something to check with Kendryte or Sipeed. VisualGDB uses the OpenOCD port maintained by Kendryte to debug the K210 device, so if it supports this probe, VisualGDB will work with it as well.

If you can confirm that running OpenOCD manually works, we can help you edit the .xml files used by VisualGDB so that it will detect the probe and will show it in the GUI the same way it does it for other supported probes.

When you select Segger J-Link instead of OpenOCD, you are switching to the J-Link debug software – a tool maintained by Segger that allows interfacing gdb to the J-Link. Please check with Segger whether they have any plans for supporting the K210 device – this is completely up to them and is outside our control.

[support]

Hi,

You can always achieve this by creating custom MSBuild targets via editing the .vcxproj file. It is much less straight-forward than the custom steps provided by the VisualGDB Custom Edition, but will work just fine once you get familiar with the MSBuild internals.

[support]

Hi,

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

[support]

There is no need to regenerate the batch files unless you change global parameters, such as the toolchain or the environment. The batch files simply invoke CMake to parse the CMakeLists.txt files, generate the actual build rules, and then build the project with them. This workflow will automatically pick up any changes in CMakeLists.txt and the source files.

Here’s the contents of a typical batch file for CMake:

cd /d C:\projects\temp\DemoProject\build\VisualGDB\Debug
set LANG=en_US.UTF-8
set PATH=c:\SysGCC\arm-eabi\bin;%PATH%
set TOOLCHAIN_ROOT=c:/SysGCC/arm-eabi
set EFP_BASE=C:/Users/virtual.SYSPROGS/AppData/Local/VisualGDB/EmbeddedEFPs
set TESTFW_BASE=C:/Users/virtual.SYSPROGS/AppData/Local/VisualGDB/TestFrameworks
set TESTFW_BASE_LOCAL=C:/Users/virtual.SYSPROGS/AppData/Local/VisualGDB/TestFrameworks
"C:\Users\virtual.SYSPROGS\AppData\Local\VisualGDB\CMake\bin\cmake.exe" ../../.. -G "Ninja" -DCMAKE_BUILD_TYPE=DEBUG -DTOOLCHAIN_ROOT=c:/SysGCC/arm-eabi -DCMAKE_MAKE_PROGRAM="C:/Program Files (x86)/Sysprogs/VisualGDB/ninja.exe" -DCMAKE_TOOLCHAIN_FILE=<...>/toolchain.cmake -DPLATFORM=VisualGDB -DLOCALAPPDATA=C:/Users/virtual.SYSPROGS/AppData/Local

It references various common paths and the toolchain.cmake file, but doesn’t contain anything that would change when you add a new source file or a target.

[support]

Hi,

This looks like your VisualGDB installation is corrupt. Please make sure you are using an unmodified installer and do not edit any files or registry entries.

If nothing helps, please attach a screenshot of the Help->About VisualGDB window.

[support]

Thanks, this is a different issue. When using the VisualGDB.exe /build or /rebuild command for Advanced CMake projects, it was not properly passing the build type to CMake, so it ended up building the debug configuration (despite using the release folder).

We have fixed it in this build: VisualGDB-5.6.3.4195.msi

We also recommend building Advanced CMake projects by dumping the build/configuration command lines to batch files as shown here.

[support]

Please double-check the values of __StackLimit  and __StackTop  per our previous reply.

[support]

Hi,

If you believe VisualGDB is working incorrectly, please provide complete unambiguous steps to reproduce the problem from scratch. The steps should start with creating a new project, and should either mention every involved setting, or include screenshots of every involved wizard/settings page and every other change. They should also include any relevant logs.

Please see our problem reporting guidelines for more details.

[support]

Hi,

This is by design. Unless you do a full rebuild, the build system only builds the files that are out-of-date (i.e. the sources have changed more recently than the objects). Files that are up-to-date are not rebuilt and the warnings that were shown during their compilation will not be shown again unless these files become out-of-date again. This is standard behavior for all build systems we are aware of and is not specific to VisualGDB.

[Author]

Posts