[support]

Hi,

Thanks very much for sharing this, it is indeed a VisualGDB bug. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.8.1132.msi

Please open your VisualGDB Project Properties and change the Include Directories field arbitrarily (e.g. add and remove a space), then press OK. VisualGDB will then update the CMakeLists.txt correctly.

[support]

Hi,

According to your log, there are 2 definitions of the posix_memalign() function:

1. C:\Users\akhils\AppData\Local\VisualGDB\RemoteSourceCache\192.168.0.54\0001\include\mm_malloc.h(34,64)
2. C:\Users\akhils\AppData\Local\VisualGDB\RemoteSourceCache\192.168.0.54\0000\include\stdlib.h(503,12)

This normally means that your system is too old and does not support C++11 properly. You can try patching the headers to have matching definitions at your own risk, but you may encounter further problems with C++11 on that system.

[support]

Hi,

This one can be safely ignored and should be solved in the upcoming Beta 1.

If everything else works, we would recommend simply updating to Beta 1 once it is released.

[support]

Hi,

The “127.0.0.1” address always refers to the “current machine”, so if you try to connect to 127.0.0.1 from VisualGDB, it will try to connect to the Windows machine itself and will not work. Please use the “ifconfig” command on the Linux machine to find our its actual IP address and use it instead. Please also ensure that your VM network settings are configured in a way that allows the two machine to communicate with each other (e.g. bridged connection to your local network).

[support]

Hi,

Oops, his looks like a bug. Does the C:/root-directory-of-application/=/opt/libName/include path appear on the command line, or does it only appear in the verbose GCC output? Perhaps some other setting or a small typo somewhere is interfering with it? Could you share the entire build log showing the command lines and the diagnostic output from gcc?

[support]

Please try downloading the latest version of msp430.dll from TI and replace the one in the msp430 toolchain directory with it.

We also recommend updating the firmware on your USB programmer to the latest version as sometimes old firmware causes strange problems.

[support]

Hi,

You can build the OpenOCD fork that we use from the sources here: https://github.com/sysprogs/openocd

You can use this MinGW environment that has all the necessary libraries: http://sysprogs.com/files/tmp/MinGW.7z

Simply search the source code for the “Cannot identify target as a STM32L4 family” line and you will see the table that checks the device IDs and selects the FLASH size based on them. Adding your device there should solve the problem.

[support]

Hi,

This happens because the latest SDK from ST expects your projects to define this variable in the HAL configuration file (e.g. stm32f4xx_hal_conf.h). As the file is a part of your project and may have been modified, VisualGDB does not update it automatically. The easiest solution would be to simply create a new project using the new BSP and copy the default LSE_STARTUP_TIMEOUT definition from it.

[support]

We have answered the question about the memalign() function in this thread.

Regarding the <vector> file, can you confirm that it is physically present somewhere under C:\Users\akhils\AppData\Local\VisualGDB\RemoteSourceCache\192.168.0.54? You can also try reloading the cached directories via VisualGDB Project Properties to ensure you get the latest versions of all files.

[support]

Hi,

Looks like your system headers may be too old and don’t support C++11 properly. Please examine the build output and try to understand why they have 2 different definitions of posix_memalign(). Once you locate both definitions, you can try modifying them to ensure they both match.

[support]

Hi,

Most likely there is a typo somewhere in the settings. Please try adding the -v option to CFLAGS/CXXFLAGS to force gcc to output the include search directories it uses. Then simply compare the listed directories with the command line shown in the build log. This should explain why the file is not found.

[support]

Please start with trying this Makefile literally:

test:
<TAB>gcc -DTIMESTAMP=$(shell C:/mingw/msys/1.0/bin/date.exe +%s) -E test.c -o test.E

If it works, with your make.exe, please compare the syntax in it with your Makefile that is broken. If it does not, please download a clean MinGW toolchain from here and try using make.exe and mingw-make.exe from it.

[support]

Hi,

This is a known issue. Basically, OpenOCD does not know the current device ID and cannot detect the FLASH characteristics for it:

Warn : Cannot identify target as a STM32L4 family.

Normally the device IDs are added by the OpenOCD maintainers fairly quickly, so we would recommend simply waiting a month or two until an update is available. We could also provide brief instructions on building OpenOCD from scratch and patching it to support the new device if you don’t want to wait for the OpenOCD guys to do that for you.

[support]

Hi,

Please try adding “-std=c++11” to the CXXFLAGS field in VisualGDB Project Properties.

[support]

Good to know it works. If you ever need our help to pinpoint the toolchain issue, feel free to share the error messages you get and we will give our best advice on figuring out what could be the cause.

[Author]

Posts