[Aristarchos]

Just tested it and that build solves the device issue ok.

Regards

[Aristarchos]

Thanks for answering.

But that option does not exist..

I send you a screenshot of what I see and the VisualGDB version.

Regards

Attachments:

You must be logged in to view attached files.

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

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

 

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

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

 

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

[Aristarchos]

After some checking, I think I found the cause for the partition table visual error and why the idf.py reports a overlap error when flashing.

There are two problems.

At first the contents of the example partition.csv file need to change a bit as they do not have the commas at the end of two lines, so I guess the VisualGDB GUI partition element cannot load and view it correctly

The original partitions.csv file had these contents

# Name, Type, SubType, Offset, Size
nvs, data, nvs, 0x9000, 0x6000
phy_init, data, phy, 0xf000, 0x1000
factory, app, factory, 0x10000, 3M,


Whereas it should have these, the comas at the end of lines

# Name, Type, SubType, Offset, Size
nvs, data, nvs, 0x9000, 0x6000,
phy_init, data, phy, 0xf000, 0x1000,
factory, app, factory, 0x10000, 3M,


After that change the GUI Partition element is working ok.

It looks though that the build process do not care about the commas and it succeeds at building the partition.bin file.

Now, the other problem, where the idf.py flash is reporting an overlap error, as I see it, its not due t the partition.bin, but rather on the bootloader.bin file.

From what I know, the bootloader should be flashed at 0x1000, the partition table at 0x8000 and the application at 0x10000.

The bootloader.bin has to be loaded at address 0x1000 and then the partition.bin to be loaded at 0x8000, that means there is a space of 28672 bytes for the bootloader to be flashed.

Well, the produced bootloader.bin file (of a esp-adf example with custom partition table) exceeds that size limit and it is 29552 bytes, so eventually it does not fit in.

In later toochains (2021r1, 2021r2), there is a flag “CONFIG_BOOTLOADER_COMPILER_OPTIMIZATION_SIZE=y” so the bootloader.bin remains small in size even to a esp-adf example with custom partition tables.

I tried to apply manually this flag adding it to the sdkconfig of the ‘record_while_play’ esp-adf example that has the custom partition table, but to no avail, it got rejected and removed from the sdkconfig file when build the project (with the only old toolchain GCC520GDB710r17 that is known so far that works).

So to recap, the visual aspect of partition table error can be get fixed by strictly enforcing csv rules to the partition.csv file by adding the missing commas.

But I do not know how the excessive size of the bootloader.bin can be reduced with the old toolchain GCC520GDB710r17.

 

[Aristarchos]

Ok, thank you for explaining but I kinda knew that.

Anyway, I do not want to know what the differences are between toolchain versions, just want to have environment that works with the things I’m looking at now.

These are the latest ESP-ADF with custom partition tables and the ability to use the IDF Component Manager. For both it looks that I need to have 2021r2 toolchain which from what I understand it is not available yet from VisualGDB, I hope in due time will be.

[Aristarchos]

Ok, thanks for the explanation on the cmdline for idf.py in VisualGDB.

And yes, I can confirm that the other standard esp-idf/adf and eclipse work just fine all the way from build, flash up to monitor checking.

 

Regarding toolchains, I cannot find the same toolchain in your downloads, the latest one that resides in your toolchain downloads gives this regarding its version

C:\SysGCC\esp32\tools\xtensa-esp32-elf\esp-2021r1-8.4.0\xtensa-esp32-elf\bin>xtensa-esp32-elf-cc –version
xtensa-esp32-elf-cc (crosstool-NG esp-2021r1) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 

Whereas the one that is used with ‘standard’ espressif’s idf-install is this

C:\esp\.espressif\tools\xtensa-esp32-elf\esp-2021r2-8.4.0\xtensa-esp32-elf\bin>xtensa-esp32-elf-gcc.exe –version
xtensa-esp32-elf-gcc.exe (crosstool-NG esp-2021r2) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 

Whereas the difference is 2021r1 vs 2021r2

From what I see, there is no such toolchain (esp-2021r1-8.4.0) in your toolchain downloads, do I miss something?

 

[Aristarchos]

Tried quite a few times to see and understand what happens.

 

the current situation is this: using the record_while_play example project, VisualGDB (v5.6) with the older VisualGDB provided toolchain (gcc5.2.0 gdb7.10 r17) and the ESP-ADF v2.3, can load and configure successfully the project, then it builds it ok (according to the logs), in both the environments, command line via batch export and VisualGDB GUI.

I could not find a way to execute in command line the idf.py flash, so I used ony the GUI’s method of selecting “Program FLASH Memory” in the project properties at solution explorer.

With that method, the operation failed whereas the system reported partition overlaps, I’m attaching the error screenshot.

So, as it seems although the build succeeds in both batch and GUI VisualGDB, the produced binaries cannot be used for flashing.

 

As I mentioned earlier, I do have in another system, ‘regular’ esp-idf installed for building in command line and also in eclipse. In these environments (idf-cmdline & eclipse) the same process compiles ok, flashes eith idf.py flash and also runs ok viewing the monitor. I can provide full output logs if needed from all stages (environment details, build, flash, monitor)

By checking the various parameters in contrast, seen that in VisualGDB latest toolchain that I use is the 2021r1 whereas in the espressif’s environment (idf-installer:master build by me) the toolchain is 2021r2, do not know though if that is the reason for the different results.

For sure, as I see it, VisualGDB still has an issue with ESP-ADFv2.x specifically with custom partition table projects, it also looks that it is more than a simple GUI element change, most likely something deeper, or it could be espressif’s work moving too fast relying in newer toolschains.

Attachments:

You must be logged in to view attached files.

[Aristarchos]

In the system that I have for VisualGDB, I have -only- VisualGDB and nothing else eg esp-idf and/or eclipse, in order to have it as clean as it can be from any conflicts.

 

So, since I do not have the ‘standard’ esp-idf how can I use the “idf.py -p COMx flash” working? is there a way to do that in a system with only VisualGDB? (please excuse me for such questions but I’m quite new in this tool)

[Aristarchos]

Well, I performed the outside of VisualGDB build and it shows no fail in any stage, it concludes ok, bear in mind that also in the GUI VisualGDB it was reporting successful build too. The problem is that in the Project Explorer the Partition Table visual item shows the error that I mentioned in the first post and screenshot.

It seems to me now that I’ve seen the actual VisualGDB logs (Configure/Build) that it is a VisualGDB GUI issue, the Partition Table item in Project Explorer misbehaves when specifically a ESP-ADFv2.x custom partition table project is loaded.

Partition Table binary gets built ok but the relevant GUI item fails to read properly what its in the project (and we cannot edit that table if we want to).

Attachments:

You must be logged in to view attached files.

[Aristarchos]

Hi,

Thanks for the reply, though, there is no “Clean and Reconfigure CMake Project” menu item in the VisualGDBv5.6 .. so the relevant guide you point might not help or it will be inconclusive since we cannot follow the same steps. You can see the attached image screenshot were the aforementioned menu item does not exist.

Regarding the reproduction of the problem, it can easily be done if someone select the “record_while_play” example to build in VisualGDB from the ESP-ADFv2.x. This is not an issue of a user-developed solution, it is in any of the ESP-ADFv2.x examples which have custom partition table. So after the build everyone can see it in the Partition Table item in project explorer.

 

As an added info, I also got ESP32 Eclipse environment running ok with the same projects eg “record_while_play” which has a custom partition table definition, where I can build and run ok on a LyraT, so if it was a plain ESP-IDF issue by itself it should had an impact there too right?

Specifically, the build without VisualGDB as shown in Eclipse log is (up to the point where the partition table gets built ok) attached as a file.

 

Attachments:

You must be logged in to view attached files.

[Aristarchos]

Ok,

The new 5.6 version is handling the settings now correctly and can be seen and set.

Thanks.

[Author]

Posts