Partition Table Errors in ESP-ADFv2.x

[Aristarchos]

Ok,

Tried the new one (VisualGDB-5.6.101.4473.msi) and the visual error in displaying the partition table (without the end-line commas) is gone so now this one is fixed.

 

Regarding the bootloader.bin though with what found earlier did some investigation comparing a ‘clean standard’ esp-idf installation via the ESP-IDF Windows Installer Download here which is the latest and Espressif’s recommended way, https://dl.espressif.com/dl/esp-idf/?idf=4.4 and also performing the standard VisualGDB installation.

With Espressif’s way it installed all the necessary tools and environment for building with either command line or eclipse and the main folder is “C:\esp” and esp-idf in “C:\esp\esp-idf”.

Then I also installed the esp-adf again acording to Espressif’s instructions in “C:\esp\esp-adf”. That one includes its own, another ‘esp-idf’ folder in it.

So the overall structure with Espressif’s method is this

C:\esp
C:\esp\esp-idf
C:\esp\esp-adf
C:\esp\esp-adf\esp-idf

 

With VisualGDB, on a clean-start setup, installed on default locations the toolchain and the esp-adf by creating a new program , copy of the play mp3 control.

With the default installation steps, the relevant folders are

C:\SysGCC\esp32\esp-idf\v3.3
C:\SysGCC\esp32\esp-adf\v2.3
C:\SysGCC\esp32\esp-adf\v2.3\esp-idf

 

I built and flashed the application in both environments ok, in Espressif’s with Eclipse and in VisualGDB.

 

Was surprised to see that with Espressif’s setup, the esp-idf sources used are the C:\esp-idf and not the C:\esp-adf\esp-idf whereas in VisualGDB the esp-idf sources used are the opposite, used the C:\SysGCC\esp32\esp-adf\v2.3\esp-idf and not the C:\SysGCC\esp32\esp-idf\v3.3  .. !!

This is a major difference with VisualGDB.

Bear in mind that I have not touched or altered in any way the setups nor the build scripts or default configurations.

How I found this out, I modified the i2s_driver_install function in i2s.c file that resides in both

C:\esp\esp-idf\components\driver
C:\esp\esp-adf\esp-idf\components\driver

with a simple but different printf on each and seen this way which one is actually used by the build tools/environment.

I did the same method with VisualGDB and the same i2s_driver_install function in i2s.c in both

C:\SysGCC\esp32\esp-idf\v3.3\components\driver
C:\SysGCC\esp32\esp-adf\v2.3\esp-idf\components\driver

 

I do not know if this ‘esp-idf’ folder within the ‘esp-adf’ is meant to be used, but from what I see Espressif’s tools they do not use it, they ignore it.

VisualGDB on the other hand does use this included folder and ignores the main/outside esp-idf.

Did that test twice to make sure of it.

 

If you want to know what is installed in plain-default Espressif setup is this

C:\esp\esp-adf\esp-idf>git describe --tags
v3.3.2-107-g722043f734
C:\esp\esp-adf>git describe --tags
v2.3-67-g138ac28
C:\esp\esp-idf>git describe --tags
v4.3.1

And in VisualGDB is this

C:\SysGCC\esp32\esp-adf\v2.3\esp-idf>git describe –tags
v3.3.2-107-g722043f734
C:\SysGCC\esp32\esp-adf\v2.3>git describe –tags
v2.3
C:\SysGCC\esp32\esp-idf\v3.3>git describe –tags
v3.3-rc-24-g148a26980
`

 

Regardless of what toolchain is installed, it looks to me this is a major difference in how VisualGDB handles the esp-adf in contrast to the standard Espressif build tools.

 

• This reply was modified 3 years ago by Aristarchos.

[support]

Hi,

Indeed, since the ESP-ADF installation includes its own copy of ESP-ADF, VisualGDB simply reuses it. However, as you have pointed out, the latest version of the ESP32 Eclipse environment ignores it and explicitly references the ESP-IDF checkout that is installed separately.

The easiest way to replicate the results from the Eclipse-based environment would be to go into the C:\SysGCC\esp32\esp–adf\v2.3\esp–idf folder and run “git checkout v4.3.1” followed by “git submodule update –recursive“. We have also created a Github issue suggesting that Espressif updates the ESP-ADF->ESP-IDF reference to match what is fetched by the online installer.

[Aristarchos]

To make it clear, itsa not only Espressif’s Eclipse environment that builds this ok, also the command line esp-idf tools without the Eclipse they build the same as Eclipse.

So, its only the VisualGDB that is building this in a different way. Even though as you say that underneath VisualGDB you use the same build tools. Eventually, something is different only with VisualGDB when performing a esp-adf build.

 

[support]

No problem, we have added a section about ESP-ADF to our ESP-IDF documentation page, explaining what is done differently, and the rationale behind it.

[Aristarchos]

It seems that what you indicate in the new ESP-IDF documentation page, it is not working as described.

Tried to use the latest available toolchain (gcc840gdb810r6) with the above mentioned method by adding a new esp-adf example program and it failed, it did not even reached the point to create the new program folder.

I’m attaching the error message log (error1.txt) during the new program creation in this scenario.

 

Also tried to use the older toolchain (gcc520gdb710r17 which supposedly was working with esp-adf) and again applied the aforementioned by you method of bringing the included in esp-adf, esp-idf, to the v4.3.1 (which btw builds ok with Espressif).

Again this failed, though managed to pass the program folder creation, but it could not display the project, the screenshot is error2.png

 

You blame Espressif for those issues, but in their tools (since Aug) these operations work ok and the build is fine.

I like VisualGDB more than Eclipse for some reasons, but it seems to me that it needs more to be done for having the esp-adf properly supported. Please do not take me wrong, but I just suggest you to see how this can be really solved in VisualGDB.

 

Attachments:

You must be logged in to view attached files.

[support]

Please try commenting out the last line (with the ${IDF_PATH}) in the c:\SysGCC\esp32\gcc840gdb810r6\esp-adf/v2.3\esp-idf\requirements.txt file. This should get past the error message and let you create the project.

[Aristarchos]

Ok, yes this latest hint helped.

 

So,

1. having installed the latest available toolchain gcc840gdb810r6 from VisuaGDB
2. specified the ESP-ADF v2.3 as SDK
3. followed the previous hint of getting the ISP-IDF v4.3.1 checkout in esp-adf\2.3\esp-idf
4. and manually modifying the requirements.txt file

the esp-adf projects with custom partition table finally gets compiled ok and also generating the proper .bin files, flashed and run ok too (in a LyraT development board).

 

Now, hopefully you could find a way to create a new VisualGDB version that takes these too into consideration. More likely not to use the esp-idf folder within esp-adf since espressif is not using it, as it seems this is the root cause of most of the problems mentioned (and solved) in this thread.

 

[support]

We have already updated VisualGDB on our side to handle requirements.txt in this case correctly and will include this fix in the upcoming VisualGDB 5.6R2.

Regarding the versions, if we updated VisualGDB to use the latest ESP-IDF with ESP-ADF, instead of the version referenced as a git submodule, it is only a matter of time until the next ESP-IDF update (that was never tested with ESP-ADF) would break everything.

E.g. according to the ESP-ADF documentation, the supported ESP-IDF versions are 3.3.2, 4.0 and 4.1, so the Espressif’s online installer putting together ESP-ADF 2.3 and ESP-IDF 4.3.1 is contradicting their own documentation. It does resolve the bug you encountered, however it might introduce other bugs and it’s generally something for Espressif to figure out and document.

We have provided detailed explanation why VisualGDB uses the ESP-IDF submodule inside ESP-ADF on our documentation page, along with instructions for manually switching the ESP-IDF version. We will not change the default behavior, as it would likely introduce more problems as newer ESP-IDF versions are released.

[Aristarchos]

Ok,

I have seen and followed the https://github.com/espressif/esp-adf/issues/717 issue opened from VisualGDB.

To be honest I do not see anything in Espressif’s comments that mentions they will continue to use the ‘supplementary’ esp-idf, instead they mentioned something that its not entirely clear (at least for me) on what they will do: “and the latest MR(supplementary supported IDF version) will be merged into the master branch soon.”

So, eventually we just have to wait and see how this will be handled by them in due time.

[Author]

Posts