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

[support]

It looks like OpenOCD fails to program the FLASH memory:

[    3516 ms] &"Error finishing flash operation\n"

This might be caused by a bug in the STM32L4 FLASH driver that sometimes doesn’t work when programming small ELF sections. Our best advice would be to try comparing the project that can be programmed with the one that triggers the error (e.g. using the Embedded Memory Explorer), and try eliminating the differences between them. Alternatively, please try using Segger J-Link. It comes with its own fully supported GDB stub that replaces OpenOCD and usually works much more reliably.

[support]

Thanks, the relevant part of the log is this:

[     105 ms] -target-select remote :3333
[    1122 ms] ^error,msg=":3333: No connection could be made because the target machine actively refused it."

It looks like gdb is indeed trying to connect to port 3333. Please try the following steps:

1. Reproduce the problem, but don’t press Retry yet.
2. Run “telnet localhost 3333” from another window (you may need to install Telnet client via Add/Remove Programs -> Windows Features).
3. If the telnet connection succeeds, close the telnet window and retry the gdb connection.
4. If the telnet connection fails, double-check that OpenOCD is listening on the port via netstat and that it doesn’t show any errors in the output window when you try to connect to it.

If you still cannot connect to OpenOCD, please try running it manually and check whether connecting via telnet works.

[support]

Please use the first page of VisualGDB Project Properties to change the MCU type.

[Author]

Posts