Page 2 of 2

Re: Failure to provision with 4.x IDF but works with 3.3 IDF

Posted: Fri Dec 20, 2019 3:31 pm
by jsam589
Can you provide steps for updating the toolchain? I have never done that step. I usually install an entire version of IDF. I am on Linux and usually set IDF_TOOLS_PATH and then run install.sh. My current setup is Linux 64-bit Ubuntu 18.04, IDF 4.0-beta2.

I have downloaded and unpacked the r2 toolchain file
xtensa-esp32s2-elf-gcc8_2_0-esp-2019r2-linux-amd64.tar.gz
It created folder xtensa-esp32s2-elf which has 1893 items totalling 282 MB.

What do I do now?

My ~/.profile contains these lines currently:

Code: Select all

export IDF_TOOLS_PATH=~/Esp_Idf_Versions/4_0_beta2/tools
export IDF_NVS_GEN=$HOME/Esp_Idf_Versions/4_0_beta2/esp-idf/components/nvs_flash/nvs_partition_generator/nvs_partition_gen.py
. $HOME/Esp_Idf_Versions/4_0_beta2/esp-idf/export.sh

Re: Failure to provision with 4.x IDF but works with 3.3 IDF

Posted: Mon Dec 23, 2019 6:18 am
by Mahavir
You will have to update your $PATH environment variable to point to /path/to/xtensa-esp32-elf-gcc8_2_0-esp-2019r2-linux-amd64/xtensa-esp32-elf/bin/ directory.

Code: Select all

echo $PATH
export PATH="/path/to/xtensa-esp32-elf-gcc8_2_0-esp-2019r2-linux-amd64/xtensa-esp32-elf/bin/:$PATH"
Post this just ensure that command `xtensa-esp32-elf-gcc --version` gives correct toolchain version before starting build for ESP-IDF. Refer at https://docs.espressif.com/projects/esp ... -the-tools for more details

Re: Failure to provision with 4.x IDF but works with 3.3 IDF

Posted: Mon Dec 23, 2019 1:33 pm
by jsam589
There seems to be a slight discrepancy of the file names. When I unzip this file:

tar -xzvf ~/Downloads/xtensa-esp32s2-elf-gcc8_2_0-esp-2019r2-linux-amd64.tar.gz

The directory that is created is xtensa-esp32s2-elf (notice the "s2" is part of the name).

Then in the bin directory, all the binary executable files begin with "xtensa-esp32s2-", e.g. xtensa-esp32s2-elf-gcc

Will the build tools account for the need for "s2" to be in the executable name?

Also, there are many other directories (include, lib, libexec, share) created besides bin. These won't be known by the PATH. Will the bin files run correctly without the knowledge of where all these other related files are located?

Re: Failure to provision with 4.x IDF but works with 3.3 IDF

Posted: Mon Dec 23, 2019 4:56 pm
by Mahavir
Seems like you have downloaded toolchain for `esp32s2beta` chip. Can you please download latest toolchain for `esp32` from https://dl.espressif.com/dl/xtensa-esp3 ... d64.tar.gz?

Re: Failure to provision with 4.x IDF but works with 3.3 IDF

Posted: Wed Dec 25, 2019 4:43 pm
by jsam589
Another step forward! I find that the line to update PATH must be placed AFTER export.sh has run, or else Linux boot hangs due to complaint about tool path. But the following works in my ~/.profile:

Code: Select all

# IDF v4.0-beta2, 2019r2 toolchain applied
# DOES NOT WORK HERE: export PATH="$HOME/Esp_Idf_Versions/4_0_beta2/tools_r2/xtensa-esp32-elf/bin:$PATH"
export IDF_TOOLS_PATH=~/Esp_Idf_Versions/4_0_beta2/tools
export IDF_NVS_GEN=$HOME/Esp_Idf_Versions/4_0_beta2/esp-idf/components/nvs_flash/nvs_partition_generator/nvs_partition_gen.py
. $HOME/Esp_Idf_Versions/4_0_beta2/esp-idf/export.sh
export PATH="$HOME/Esp_Idf_Versions/4_0_beta2/tools_r2/xtensa-esp32-elf/bin:$PATH"
When I check the gcc version, I get this.

Code: Select all

refact_oct2019$ xtensa-esp32-elf-gcc --version
xtensa-esp32-elf-gcc (crosstool-NG esp-2019r2) 8.2.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.
And now, my software is provisioning and running successfully with Azure. No cert/key errors. And able to use SPIRAM. Thanks for sticking with me to get this all figured out!

IMPORTANT REQUEST FOR GOING FORWARD:

I want to permanently change to use 4.0 IDF (from 3.3.1) as soon as I can for my project. But in order to do so, I would want 2019r2 toolchain included automatically when using install.sh/export.sh. It should not require manual patching. Do you think this will be the case by the time 4.0 is officially RELEASED?

Thanks!

Re: Failure to provision with 4.x IDF but works with 3.3 IDF

Posted: Thu Dec 26, 2019 5:50 am
by Mahavir
I want to permanently change to use 4.0 IDF (from 3.3.1) as soon as I can for my project. But in order to do so, I would want 2019r2 toolchain included automatically when using install.sh/export.sh. It should not require manual patching. Do you think this will be the case by the time 4.0 is officially RELEASED?
Yes, with next 4.0 release (be it final one or beta3), toolchain will be default set to 2019r2.