[support]

No problem. As soon as you renew your license, we should be able to help you further.

[support]

Hi,

This one unfortunately looks like a bug in gdb itself:

-var-create --frame 0 --thread 1 - * "Status"
^done,name="var23",numchild="1",value="{...}",type="CReturnCode",thread-id="1",has_more="0"
-var-list-children --simple-values "var23\.public" 0 5
bash: line 1: 25479 Segmentation fault (core dumped) /work/apm/crosstools/apm-aarch64/8.0.10-le/bin/aarch64-apm-linux-gnu-gdb -interpreter=mi --args uxx n=2

The easiest way to resolve this would be to try building a newer gdb from source code (it’s usually much easier than building the entire toolchain and just involves running ./configure –target=<…> and making sure you have libexpat available). Another option would be to try specifying another debug information format in build settings (e.g. DWARF-2 or DWARF-4) or simply avoiding the evaluation of the variable that triggers the crash.

[support]

No problem. We can help you track it down, however we would first kindly ask you to renew your license and update to the latest VisualGDB 5.4 as the issue you have might be specific to an older VisualGDB version.

[support]

Hi,

This looks like the libstdc++ library bundled with your GCC may not contain the implementations for some functions required by the library.

Please try building the library from sources using the same compiler. If you get c++11-related errors, the compiler does not provide the language support required by the library. If the build succeeds, the library should link to the main project without errors.

Also depending on your compiler’s multilib configuration, you may need to specify -std=c++11 to the linker flags (and also ensure you are using g++, not gcc to link).

[support]

Thanks for sharing the solution! We have updated the post.

[support]

Sorry, unfortunately there is no easy way to do this, as the Arduino build logic is handled by the Arduino builder and not directly by VisualGDB.

You should be able to extract the gcc command lines by parsing the VisualGDBCache\<Target>\CodeModel.json file, extracting the gcc arguments from there and running it manually with the -S option instead of -c, although that would require some scripting on your side.

[support]

Hi,

Looks like you forgot to specify the “–interpreter mi” argument in the gdb command line. This argument is required in order to enable the “machine interface” – a special mode where gdb produces machine-readable replies to commands instead of the regular text replies.

VisualGDB would normally handle this automatically for the regular debug configurations, however using the fully custom mode shown on the screenshot requires specifying it manually.

[support]

Hi,

It looks like the project has some leftovers from the previous BSP version, or previous configuration. Please try rebuilding it via Build->Rebuild All.

[support]

According to our records, the recent VisualGDB updates did not change anything that could be causing this issue.

You have also mentioned several different issues in this thread that would occur under different setups, so it is hard to understand what is going on based on your description.

Please try installing the toolchain from scratch and check whether creating a new Qt5-based project for the target works.

[support]

Hi,

According to our records, your support period has expired. In order to continue receiving technical support, please renew your key here. If you have purchased a different key with another email address, please let us know or update your forum profile.

[support]

It looks like your toolchain is not compatible with your target. As a workaround, please try building the code directly on the target.

[support]

Hi,

Sorry, but the only way to tell what is going on is to check the View->Output window as suggested by the second error message on the screenshot. It will show the detailed build log that should point to a specific part of the build that failed.

[support]

Thanks for the details and sorry for the confusion. We have rechecked everything and found the root cause of the problem.

When the main application is rebuilt, the “clean” stage of the build deletes the built files from the project output directory, following the regular Visual Studio logic. This also results in deletion of the .bin file previously built by the bootloader project.

The easiest way to fix this would be to edit the “Extensions to delete on clean” field for the main project, replacing *.bin with $(TargetName).bin. This will ensure that cleaning (or rebuilding) of the main project won’t affect the .bin file produced by the tutorial project.

[support]

Hi,

You should be able to do it by editing the KConfig.projbuild file in the component directory (see the “Blink GPIO number” configuration for the blink sample).

You can find some documentation on this mechanism here: https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/build-system.html

 

[support]

Hi,

The raw terminal needs to be enabled via VisualGDB Project Properties (Raw Terminal page). If the page doesn’t appear, please double-check your VisualGDB edition via Help->About VisualGDB. If you have recently upgraded to Custom edition and the About window doesn’t reflect it, please re-enter your license key in the About window in order to apply the new edition.

[Author]

Posts