Forum Replies Created
-
AuthorPosts
-
supportKeymaster
Hi,
Yes, sorry about that. The STM32 BSP comes with different versions of the cmsis_os.h and the VisualGDB header discovery does not go deep enough to validate them.
Normally if you add references to FreeRTOS via the Embedded Frameworks page, VisualGDB should set the correct include directories automatically and you won’t need to fix anything manually.
supportKeymasterHi,
No problem. The shared library should do as well, as long as it is always present on your target system.
supportKeymasterHi,
This could happen if your toolchain is not compatible with the deployment computer. Please examine the error log shown by VisualGDB for further clues (e.g. an “invalid file format” or “invalid ELF target” message would definitely suggest a wrong toolchain being used).
supportKeymasterHi,
Yes, we have published a detailed tutorial last week: https://visualgdb.com/tutorials/arm/mbed/lpc1549/
supportKeymasterHi,
Sorry, if you want to import complex 3rd-party projects into VisualGDB, you do need to understand how to build them manually and locate/install the necessary build tools. VisualGDB can simplify a lot of the common tasks through features like automatic header discovery, but it requires understanding of the underlying build process if you want to go beyond creating & modifying basic samples that work out-of-the-box.
Our best advice would be to check with the project vendor for specific steps required to build the project under Windows.
supportKeymasterHi,
This would normally indicate a problem with the project’s Makefile and selecting a different VisualGDB configuration won’t affect this.
Please try checking if you can build the project on Windows via command line (by running make.exe manually). If not, the project’s build scripts may not be compatible with Windows and would need to be fixed before you can import the project into VisualGDB.
supportKeymasterHi,
This is actually by design and replicates the regular VS debugging experience. The watch window and hardware registers are only active when the target is stopped (e.g. at a breakpoint). To view the variables while the target is running, please use the Live Variables window.
supportKeymasterHi,
Thanks for pointing out the incorrect FLASH size. We have double-checked the Olimex board we used and it indeed has 16 megabits of FLASH, although the default 32m setting worked for us. We will investigate this further and update the tutorial. Most likely the FLASH size matters for either the ESP8266 bootloader or some part of the system library that might have been slightly different in your case.
Regarding stepping over and breakpoints, ESP8266 as only one hardware breakpoint, so debugging experience is extremely limited. It is recommended to explicitly move all the functions that you want to debug to RAM so that VisualGDB can use unlimited software breakpoints instead. Otherwise you would need to disable all breakpoints in order to do stepping (which may still not work as the xtensa gdb often gets confused with function prologues and incoming interrupts).
supportKeymasterHi,
Thanks, we have managed to reproduce this. Unfortunately this is caused by a bug in VS2017 that causes random crashes after programmatically adding files and folders to Visual C++ projects.
We have submitted a bugreport to Microsoft and are also investigating possible workarounds, but the best short-term solution would be to temporarily downgrade to VS2015.
supportKeymasterThe “xxxrker.cpp has changed since last build. Doing full analysis..” message is actually misleading here. It is always shown during code completion runs (including QuickInfo).
Feel free to try this build, it reports the reparsing events in a less confusing way: http://sysprogs.com/files/tmp/VisualGDB-5.3.1.1497.msi
supportKeymasterHi,
Unfortunately this behavior is very common with ESP8266 and ESP32. The execution simply gets stuck inside the ROM or some of the system libraries with no way of telling what is causing this.
Our best advice would be to try different FLASH settings (size/mode/speed) and different reset modes.
supportKeymasterHi,
Normally it should be as easy as adding “mraa” to the “Library names” field.
If you get a “cannot find -lmraa” error, please try the following command line on your Edison:
gcc -o HelloDemo Test.c -lmraa -Wl,-verbose
Then check the verbose link log for the actual path of libmraa.a. Once you locate it, simply copy it in the corresponding directory inside your toolchain’s sysroot and VisualGDB should be able to link your program with it.
supportKeymasterHi,
Just to double-check: you imported the project using the “specify build command line manually” mode, correct? If yes, you should not need to adjust any include/library directories in VisualGDB Project Properties (VisualGDB should not even show them as it will simply treat the project as a black box and build it “as is” using the original command-line tools).
If you are not sure, could you please attach a screenshot of the include directory settings that you had to edit?
supportKeymasterHi,
This could mean a missing configuration block. Please try flashing the
esp_init_data_default.bin
file using the serial bootloader as described here.supportKeymasterHi,
GNU Make was the original build system supported by VisualGDB from the beginning, while MSBuild support was added relatively recently. Hence many of our tutorials mention GNU Make, although we actually recommend MSBuild for all new projects.
The main advantages of GNU Make are:
- You can build Make-based projects on Linux without VisualGDB (e.g. on a continuous integration server)
- If you are familiar with GNU Make internals, you can easily hack Makefiles to add complex custom steps
If none of these are relevant to you, MSBuild will be much better because:
- It builds faster due to heavy optimization on our side
- It allows configuring build settings in a much more flexible way.
- IntelliSense immediately picks up changes to build settings, so you don’t need to synchronize them manually.
There’s actually a post in our developer blog that gives an overview of the main advantages of MSBuild over the other build systems.
-
AuthorPosts