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

[support]

Hi,

Each VisualGDB release it tested via ~100 integration tests that verify creating, building, debugging and editing of different project types, hence the problem is likely not caused by a recent VisualGDB update, but is triggered by accidental changes to some global settings (e.g. switching to an incompatible toolchain).

The “unknown QT: serialport” message means that Qt is likely missing the serial port library. You might need to install the library via the Linux package manager and then re-synchronize the sysroot.

If some projects build with the serialport library, while others don’t, the only way to get the old projects to work is to compare the working projects with non-working ones and eliminate the differences.

Unfortunately, as you have not provided any details on the other error messages you got, it is hard to suggest anything specific. If you could attach a screenshot, or the full text of the error, we can help you understand what it means.

[support]

Hi,

Please double-check that the main project properly references the bootloader project (per step 11 of the tutorial).

You can also download the source code of the projects shown in the bootloader tutorial here (we have just rechecked rebuilding and it did work as expected): https://github.com/sysprogs/tutorials/tree/master/visualgdb/ARM/BootloaderDemo

[support]

Strange. Please try setting the delay to something large (e.g. 1 minute) and then enable gdb logging via Advanced GDB Settings. Once VisualGDB begins waiting for the stub to start (i.e. delaying for 1 minute), please double-check in the gdb session log that the ‘target remote’ command hasn’t been issued yet.

If it is indeed being issued before the delay elapses, please let us know and we will investigate. If it is issued after the delay, please try the following:

• Start OpenOCD manually before the session and switch from “custom gdb stub” to “custom mode”. Check if this works as expected.
• Start OpenOCD via the “custom gdb stub” mode and set a long delay (e.g. 10 minutes). Once the delay counter appears, run gdb manually and try connecting to OpenOCD.

This should help narrow the problem down.

[support]

Hi,

The easiest way to do it would be to temporarily edit the linker script file (see the Build page of VisualGDB Project Properties to copy it to the project directory), increasing the memory size to avoid the link error, and then to use the Embedded Memory Explorer for a detailed overview of the memory utilization.

[support]

Oops, sorry we missed that the connection worked after you pressed ‘retry’.

If you are using the “Custom GDB stub” mode, you can specify additional delay via VisualGDB Project Properties -> Debug Settings -> Startup Delay.

If not, please let us know what debug mode you are using and we will help you configure the delay.

[support]

Hi,

It looks like you have changed some global setting (e.g. installed an incompatible toolchain, replaced some files in the sysroot, or edited some global file) and that is triggering problems. The best way to troubleshoot this would be to install the toolchain (and flash the SD card image) from scratch, create a new project and ensure that it works, and then either compare the new project’s settings with the old one, or simply move your old project’s files to the new one one by one. There is no easy way to just get everything to build without either knowing what exactly has changed, or re-creating a working setup from scratch.

Specifically, the libgobject-2.0.so error looks like your toolchain is either missing some files, or has been partially overwritten with incompatible versions of some files. Reinstalling the toolchain from scratch as suggested before should solve the problem.

[support]

Thanks for clarifying this. In that case you would indeed need to edit the file manually.

[support]

You can change the addresses used to place various parts of your program by editing the linker scripts. Please see the following tutorials explaining this process in details:

• https://visualgdb.com/tutorials/arm/bootloader/
• https://visualgdb.com/tutorials/arm/linkerscripts/

[support]

Hi,

This is likely caused by multiple projects referencing the same source file (or source files that only differ in the name case, e.g. FILE.c vs file.c) and can normally be ignored. If you could provide the exact steps to reproduce it, we should be able to tell more.

[support]

Sorry for the delay and good to know it works. Just FYI, if you are using the STM32 libraries, ST typically provides Keil-compatible, GCC-compatible and IAR-compatible versions of the assembly files, so you can simply pick a GCC-compatible one instead of manually editing the file that uses the Keil syntax.

[support]

It looks like your toolchain is corrupt. Please try deleting it and installing the latest one (and FLASHing a compatible SD card image) from scratch.

[support]

The page you mentioned lists compatible SD card images for each toolchain. If you are not sure which image you are using, we advise starting with a clean toolchain and a clean image compatible with it in order to avoid strange errors.

If you want to use a different SD card image, please contact the image vendor for a compatible toolchain instead.

[Author]

Posts