Forum Replies Created
-
Posts
-
The “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
Hi,
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.
Hi,
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.
Hi,
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?
Hi,
This could mean a missing configuration block. Please try flashing the
esp_init_data_default.binfile using the serial bootloader as described here.Hi,
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.
Hi,
The log with the manual reset actually looks OK. Does the program fail to start after programming in that case?
Another quick solution would be to try the Olimex ARM-USB-OCD-H programmer. It gives OpenOCD a very low-level control over JTAG and we managed to get relatively reliable debugging experience with it.
Hi,
J-Link might handle resetting differently. Please try connecting reset to SRST instead of TRST (normally pin 15). If this does not help, please try disconnecting reset completely and manually resetting the board before programming it.
Hi,
We have done some further research into ESP-IDF 2.0 and it looks like some changes to it totally break JTAG debugging and FLASH programming, so it may take us some extra time to fully figure it out.
We will have a quick look into the ESP32 tracing functionality and will assess whether it is stable enough to be supported via VisualGDB.
Hi,
It looks like the project you are trying to import contains several versions of vector_nvic.c meant for different targets, so importing all of them won’t work.
For projects with complex build scripts we recommend selecting “Specify a build command line manually” in the VisualGDB Project Wizard. This will tell VisualGDB to run the build script that came with the project, so it will follow all the complex rules defined there.
Another alternative would be to study the build scripts of the project and only import the files that are supposed to build on your target (you would also need to manually specify all the preprocessor macros that the project’s build system specifies). This approach requires more initial effort, but results in better integration between build, IntelliSense and debugger.
Hi,
Looks like your toolchain directory contains spaces in the path. As GNU Make does not support such directories properly, VisualGDB does not support them either. Please try creating a symbolic link (e.g. c:\armgcc) to the toolchain directory and using the short path instead.
Hi,
Sorry, we could not reproduce any IntelliSense problems with the attached project.
The issues you are experiencing could be caused by a corruption of the IntelliSense configuration files or the project file itself.
Please try deleting the <sysgcc>\arm-eabi\*.props files and creating another project via VisualGDB Project Wizard. This should regenerate all the configuration files.
