Forum Replies Created
-
Posts
-
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.
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.
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:
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.
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.
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.
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.
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.
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:
- Reproduce the problem, but don’t press Retry yet.
- Run “telnet localhost 3333” from another window (you may need to install Telnet client via Add/Remove Programs -> Windows Features).
- If the telnet connection succeeds, close the telnet window and retry the gdb connection.
- 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.
Hi,
Sorry, the AT91SAM7 BSP is very old and may not properly work with the latest toolchains or the MSBuild subsystem.
The build problems with GNU Make are most likely caused by the incorrect “AS” environment variable inherited from the environment. Commenting out ifeq/endif as you mentioned above should successfully work around it.
Getting MSBuild to work with AT91SAM7 could be harder, as its linker script expects a specific order of the source files, that is not guaranteed with MSBuild. We would advise using MSBuild for newer device families and GNU Make for AT91SAM7S. You can solve the “invalid instruction” error by adding the #define __ASSEMBLY__ line to the beginning of the board_cstartup.S file, however the build may still fail due to the linker input ordering.
The fast semihosting was only tested with the THUMB instruction set used by the modern embedded ARM devices, while AT91SAM7 uses the ARM instruction set by default. You can try switching the instruction set to THUMB, however the background memory reads required by the advanced semihosting may not be supported by the older ARM7TDMI core used by the AT91SAM7 devices.
Please follow the instructions from our reply in the following thread: https://sysprogs.com/w/forums/topic/problem-error-building-after-update-to-new-release/
Most likely, the problem is triggered by an accidental change of some settings of the project or a toolchain. Please try comparing the settings of the working and non-working projects (either compare each page of VisualGDB Project Properties, or compare the .vgdbsettings and .pro files using KDiff or another diffing tool) and then try editing the broken project to match the settings of the working project. If you can narrow down a specific setting, we can check whether it could be caused by a VisualGDB update and release a hotfix, however it is not possible for us to confirm it without knowing a specific setting.
