ESP-IDF -128-NOTFOUND

[mattkefford]

Hi all,

I am currently working on code for the ESP32 module and using VisualGDB in VS2019 as the IDE/build environment.

After recently switching from IDF v3.3.1 to IDF v4.0 I am having a new issue. When the module boots up, it outputs info over the serial port, included in this is the version of ESP-IDF used.

The code is compiling and flashes and boots fine, but during boot log I see this line:
“I (39) boot: ESP-IDF -128-NOTFOUND 2nd stage bootloader”

Previously this has always managed to pull in the version of IDF being used and even included specific commit number.

I downloaded and installed everything through Visual Studio/VisualGDB.

Any idea how I can point CMake or some project setting at the right place to make it pull this information in properly?

I have checked my paths and they are correct:

Log that is output at boot:

Other Info:

• Development Kit: ESP32-Wrover-Kit
• Kit version: v4.1
• Module or chip used: ESP32-WROVER
• IDF version: v4.0
• Build System: CMake
• Compiler version: xtensa-esp32-elf-gcc.exe (crosstool-NG esp-2019r2) 8.2.0
• Operating System: Windows
• (Windows only) environment type: ?
• Using an IDE?: Yes Visual Studio + VisualGDB
• Power Supply: USB

<h2></h2>
 

[support]

Hi,

This looks like an issue specific to ESP-IDF and not something VisualGDB-specific. Please try building and programming the project via command line and check if the problem persists.

If yes, please contact Espressif for support. If not, please let us know more details (build logs and the output from the device when building manually vs. with VisualGDB) and we will help you configure VisualGDB to replicate the results of the manual build.

[mattkefford]

Hi, thanks for your reply.

Previous to this I have setup the toolchain by following the ESP Getting Started guide, which installs the toolchain and clones an IDF and then configures the env variables. Whenever I have done that, it works fine.

I came here to seek help because I am now settings everything up using just the VisualGDB GUI and it is the first time I have had this problem. So I presumed it must be a VisualGDB issue.

Building the program from command line it actually doesn’t build as it can’t pull in the header files, so this is my only option at the moment…

 

[support]

No problem and thanks for confirming it. Most likely, the problem is caused by some differences between the VisualGDB toolchain and the manually imported toolchain. So our first advice would be to try downloading one of our older toolchains that has the same ESP-IDF version number.

If it doesn’t help, please try importing the toolchain that works into VisualGDB as shown below:

1. Copy the toolchain.xml file from one of our toolchains into your toolchain directory and replace the revision number in it with 1000.
2. Make sure the BinaryDirectory and Prefix elements in toolchain.xml makes sense (they should point to the toolchain’s binaries same way the do for our toolchain).
3. Copy the entire esp32-bsp subdirectory from our toolchain into the imported toolchain
4. Copy the IDFCheckouts.xml file from our toolchain and edit it to have the correct ESP-IDF version and the correct relative path to the directory where you have ESP-IDF. This will make sure VisualGDB sets the environment correctly. You can add “(manual)” to the ESP-IDF version to distinguish it in the VisualGDB GUI.
5. Finally, open VisualGDB Project Properties for your project, locate the toolchain selector and click “Import a toolchain by locating its gdb” and point VisualGDB to the toolchain.xml of the manually imported toolchain.
6. Make sure you have the correct ESP-IDF version selected as well. It should match the version specified at step 4.

If you still get different results from the manual build, please locate the command line in the VisualGDB build log (shown in cyan), right-click on it and dump it to a batch file. It will save the environment set by VisualGDB when launching the build command, so you can compare it side-by-side with your own batch file and produces correct results. Eliminating half differences at a time and checking if the results are still different should help find the root cause in just a few steps.

Let us know if you encounter any issues along the way. Helping you getting equivalent results to the manual build is fully covered by our support and we will be happy to help.

[Author]

Posts