[support]

Hi,

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

[support]

Hi,

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.

[support]

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

[support]

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.

[support]

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.

[support]

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?

[support]

Hi,

This could mean a missing configuration block. Please try flashing the esp_init_data_default.bin file using the serial bootloader as described here.

[support]

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.

[support]

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.

[support]

Hi,

Thanks, we will investigate and fix it in the upcoming v5.3.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[Author]

Posts