[support]

Hi,

This happens because the esp-idf repo does not actually contain all the libraries. Instead they are automatically downloaded first time you build a project with it.

Hence the recommended procedure is to build one of the sample projects from esp-idf on Linux and then copy the esp-idf directory on Windows and try generating a BSP from it.

We will look into updating our ESP32 toolchain once the esp-idf 2.0 reaches the final release stage.

[support]

Hi,

Perhaps something in your setup is removing the environment variable before launching msbuild?

Please try running “echo %VISUALGDB_DIR%” just before launching MSBuild. This should output the VISUALGDB_DIR variable.

[support]

Hi,

This is by design. VisualGDB relies on Visual Studio to handle the project dependencies. Please either create a .bat file that will build all the projects, or build the .sln file by running devenv.exe or msbuild.exe from command line.

[support]

Hi,

Thanks. Are you using the latest VisualGDB 5.2R8? If not, please try updating. You can also force VisualGDB to update the file references by clicking on a different MCU on the first page of VisualGDB Project Properties and then selecting the current one back and pressing “Apply”.

[support]

Hi,

This is indeed strange. Could you please attach your .vgdbsettings file or send it to us via the support form? This should help us see if this is a VisualGDB bug.

[support]

Hi,

OK, thanks for the GDB log. It looks like the FLASH programming code does not report any errors (code 0 below):

-data-evaluate-expression “\*\(\(unsigned\ \*\)0x3fff8014\)”
^done,value=”0″

so normally the program should work. Are you able to communicate with the board using the esptool.py? If yes, could you try reading the FLASH memory at addresses 0 and 0x10000 and comparing it with the OMC-<address>.bin files?  This should explain if the FLASH gets programmed at all.

We have also ordered a NodeMCU board and should get it by the end of March. We will check it once it arrives as post a detailed tutorial.

[support]

Hi,

The “Invalid configuration” would happen if you have accidentally deleted the file with per-configuration flags. The easiest workaround would be to re-create the project.

Please note that for new projects we recommend using MSBuild as it is faster and more flexible.

[support]

Hi,

Sorry, this is not supported on MSBuild yet. As a workaround, please try running pkg-config and adding the flags manually.

[support]

Hi,

This is expected as GNU Make uses absolute paths in the dependency files. Please try rebuilding the project (Build->Rebuild All) instead of just building it.

[support]

Hi,

It’s hard to say why this happens without seeing the debug log. Please enable gdb logging on the Advanced GDB Settings page and check the debug log for messages explaining the unexpected end of session.

If you are not sure, please attach the debug log here and we will help you pinpoint the problem.

[support]

Hi,

Thanks for your feedback. Although this is not possible now, we have added a note to the v5.3 feature list and will add an option to start renaming via a menu command.

[support]

Hi,

No problem. If you encounter further issues, feel free to contact us again.

[support]

Hi,

As usual with ESP8266, it’s hard to say for sure. Something on the board may be interfering with JTAG or something in the board firmware may be interfering with FLASH programming. As those things are not really documented, unfortunately we can only guess here.

BTW, you can use VisualGDB with the UART gdb stub as well (see this tutorial). This mode does not involve JTAG and should work if VisualMicro works as well.

Also feel free to attach the full gdb log so that we could check for common errors.

Regarding other questions:

1. The large project.bin file is actually not needed. It’s a default binary file containing ALL the sections from the image. It is useful on other targets like ARM or MSP430, but not on ESP8266 or ESP32. You can disable it via the VS Project Properties (Generate binary files = No). Manually programming the other 2 files should be sufficient (you can also use <SysGCC>\esp8266\esp8266-bsp\ESPImageTool.exe to program an ELF file via a COM port).
2. We never had to change the default sector/erase block sizes, but as those values are not well documented, we made them editable.
3. The names for the FLASH modes, frequencies, sizes, C1/C2 come from the esptool.py provided by Espressif and to our best knowledge specify the FLASH parameters that the ESP8266 device will use. On VisualGDB side selecting one of those changes the values in the ESP8266 image header (which is undocumented) similarly to what esptool.py does. Please double-check the exact semantics and meanings of those with Espressif.
4. The reset options you mentioned do not apply to JTAG programming. In fact, lack for reliable reset (that stops the CPU immediately after resetting before the ROM starts various background processes) is one of the main reasons why JTAG debugging is very unreliable compared to the GDB stub.

[support]

Hi,

This could happen if your firmware is putting the CPU to the sleep mode.

Please try the steps described in the following tutorial to enable the “connect under reset” mode: https://visualgdb.com/tutorials/stm32/sleep/

[support]

Hi,

Based on the log snippet you attached, this should work. Perhaps it is an extern “C” problem?

[Author]

Posts