start project with a specific SDK version

[edwardpang]

I'm new to ESP32, please help me solving this newbie question.

Following http://esp-idf.readthedocs.io/en/latest ... ng-esp-idf, I tried to specify the SDK version to v2.1.1 with the following command.

Remove ~/esp/esp-idf completely

Code: Select all

cd ~/esp
git clone https://github.com/espressif/esp-idf.git esp-idf-v2.1.1
cd esp-idf-v2.1.1/
git checkout v2.1.1
git submodule update --init --recursive

Set the IDF_PATH to folder created above.

Then build hello_world, in monitor, ESP-ISP is printed with unexpected string.
I (28) boot: ESP-IDF v3.1-dev-171-gf9ad17e 2nd stage bootloader

Why ESP-IDF is v3.1? Not 2.1.1?

[WiFive]

Did you reflash bootloader or just app?

[edwardpang]

I'm new here, so I cannot answer you directly, this is the "make flash" dump.

Code: Select all

Flashing binaries to serial port /dev/ttyUSB0 (app at offset 0x10000)...
esptool.py v2.1
Connecting.....
Chip is ESP32D0WDQ5 (revision 0)
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0220
Compressed 19424 bytes to 11464...
Wrote 19424 bytes (11464 compressed) at 0x00001000 in 1.0 seconds (effective 153.6 kbit/s)...
Hash of data verified.
Compressed 144272 bytes to 72707...
Wrote 144272 bytes (72707 compressed) at 0x00010000 in 6.4 seconds (effective 179.6 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 82...
Wrote 3072 bytes (82 compressed) at 0x00008000 in 0.0 seconds (effective 1972.8 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting...

This is the "make monitor" of hello_world:

Code: Select all

MONITOR
--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5604
load:0x40078000,len:0
load:0x40078000,len:13716
entry 0x40078fb4
I (28) boot: ESP-IDF v3.1-dev-202-g16391c2 2nd stage bootloader
I (28) boot: compile time 09:26:25
I (28) boot: Enabling RNG early entropy source...
I (34) boot: SPI Speed      : 40MHz
I (38) boot: SPI Mode       : DIO
I (42) boot: SPI Flash Size : 4MB
I (46) boot: Partition Table:
I (50) boot: ## Label            Usage          Type ST Offset   Length
I (57) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (64) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (72) boot:  2 factory          factory app      00 00 00010000 00100000
I (79) boot: End of partition table
I (84) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x05064 ( 20580) map
I (100) esp_image: segment 1: paddr=0x0001508c vaddr=0x3ffb0000 size=0x02170 (  8560) load
I (105) esp_image: segment 2: paddr=0x00017204 vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _iram_start at /home/edward/workspace/esp/esp-idf-v2.1.1/components/freertos/./xtensa_vectors.S:1685

I (111) esp_image: segment 3: paddr=0x0001760c vaddr=0x40080400 size=0x08470 ( 33904) load
I (133) esp_image: segment 4: paddr=0x0001fa84 vaddr=0x400c0000 size=0x00000 (     0) load
I (134) esp_image: segment 5: paddr=0x0001fa8c vaddr=0x00000000 size=0x00584 (  1412) 
I (140) esp_image: segment 6: paddr=0x00020018 vaddr=0x400d0018 size=0x13348 ( 78664) map
0x400d0018: _stext at ??:?

I (181) boot: Loaded app from partition at offset 0x10000
I (181) boot: Disabling RNG early entropy source...
I (181) cpu_start: Pro cpu up.
I (185) cpu_start: Starting app cpu, entry point is 0x40080df4
0x40080df4: call_start_cpu1 at /home/edward/workspace/esp/esp-idf-v2.1.1/components/esp32/./cpu_start.c:215

I (0) cpu_start: App cpu up.
I (196) heap_init: Initializing. RAM available for dynamic allocation:
I (202) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (208) heap_init: At 3FFB2978 len 0002D688 (181 KiB): DRAM
I (215) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (221) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (227) heap_init: At 40088870 len 00017790 (93 KiB): IRAM
I (234) cpu_start: Pro cpu start user code
I (252) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
Hello world!
This is ESP32 chip with 2 CPU cores, WiFi/BT/BLE, silicon revision 0, 4MB external flash
Restarting in 10 seconds...
Restarting in 9 seconds...
Restarting in 8 seconds...
Restarting in 7 seconds...
Restarting in 6 seconds...
Restarting in 5 seconds...
Restarting in 4 seconds...
Restarting in 3 seconds...
Restarting in 2 seconds...
Restarting in 1 seconds...
Restarting in 0 seconds...
Restarting now.

[edwardpang]

i know the root cause of my original question post before.
i used "-b" option during git checkout, and it's pointing to HEAD of v3.1-dev

After switching to tag v2.1 successfully, new issue comes. hello_world cannot complete build

Code: Select all

In file included from /home/edward/workspace/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/xtensa-esp32-elf/bits/gthr.h:148:0,
                 from /home/edward/workspace/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/atomicity.h:35,
                 from /home/edward/workspace/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:39,
                 from /home/edward/workspace/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/string:52,
                 from /home/edward/workspace/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/random:40,
                 from /home/edward/workspace/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_algo.h:66,
                 from /home/edward/workspace/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/algorithm:62,
                 from /home/edward/workspace/esp/esp-idf-v2.1/components/cxx/./cxx_guards.cpp:20:
/home/edward/workspace/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/xtensa-esp32-elf/bits/gthr-default.h:47:9: error: 'pthread_t' does not name a type
 typedef pthread_t __gthread_t;
         ^
/home/edward/workspace/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/xtensa-esp32-elf/bits/gthr-default.h:48:9: error: 'pthread_key_t' does not name a type
 typedef pthread_key_t __gthread_key_t;
         ^
...

[ESP_igrr]

The toolchain has been updated since IDF 2.1.1 has been released, and it has changed in a non-backwards-compatible way.
You need to use the toolchain linked to in IDF 2.1.1 documentation:

https://esp-idf.readthedocs.io/en/v2.1.1/get-started/linux-setup.html#toolchain-setup

[meowsqueak]

It's not clear to me which version new users ought to be using - is 2.1.1 the most recently released "stable" version? I see there's a v3.0-rc1 from December but it's significantly behind the v3.0 branch. I suppose it's not technically released so do you want us to avoid it, or use it and report issues?

Or is it best to just stick with 2.1.1 for now?

[ESP_igrr]

For production purposes it is recommended to use latest stable version available. At the moment, it is 2.1.1.
If you are at an early stage in the development process, it might be reasonable to develop using a more recent version (e.g. 3.0-rc1 or or the latest git version). This way, you can take advantage of newly released features, and have to make less changes when 3.0 is released as stable version. However, there is always a possibility of issues and regression in latest git version. Although each commit goes through a number of unit and integration tests before being pushed to Github, we only do many of the more time consuming tests on the pre-release and release versions.
For library developers it makes sense to check out pre-release and latest git versions, to spot any changes in IDF which affect the library. Pre-releases are also a way of giving developers a preview of API changes before the final release.

[edwardpang]

Thx, it works.

Code: Select all

I (56) boot: ESP-IDF v2.1.1 2nd stage bootloader

The toolchain has been updated since IDF 2.1.1 has been released, and it has changed in a non-backwards-compatible way.
You need to use the toolchain linked to in IDF 2.1.1 documentation:

https://esp-idf.readthedocs.io/en/v2.1.1/get-started/linux-setup.html#toolchain-setup

[meowsqueak]

For production purposes it is recommended to use latest stable version available. At the moment, it is 2.1.1.
If you are at an early stage in the development process, it might be reasonable to develop using a more recent version (e.g. 3.0-rc1 or or the latest git version). This way, you can take advantage of newly released features, and have to make less changes when 3.0 is released as stable version. However, there is always a possibility of issues and regression in latest git version. Although each commit goes through a number of unit and integration tests before being pushed to Github, we only do many of the more time consuming tests on the pre-release and release versions.
For library developers it makes sense to check out pre-release and latest git versions, to spot any changes in IDF which affect the library. Pre-releases are also a way of giving developers a preview of API changes before the final release.

Thanks for this. Is "master" considered "the latest git version" or the newest dev branch (v3.0)? I'm not sure if you're following the master-as-mainline workflow. Looks like you are, but can't be 100% sure from here...

EDIT: <additional question removed> - sorry, I remembered I'd asked this question before.

[ESP_Angus]

Thanks for this. Is "master" considered "the latest git version" or the newest dev branch (v3.0)? I'm not sure if you're following the master-as-mainline workflow. Looks like you are, but can't be 100% sure from here...

"master" is our development mainline. Master on github has run through our automated regression test suite (which includes unit testing, integration testing of WiFi/BT/other features), but hasn't had any other manual or intensive/stress testing done on it. Master is currently at v3.1-dev (ie early development of v3.1).

The "release/v3.0" branch broke off from mainline when we took the "v3.0-rc1" tag and is being updated with fixes to bugs found testing v3.0 (these fixes go to master at the same time). The release/v3.0 branch will become the v3.0 final stable release (which will be a git tag "v3.0").

To reiterate what Ivan said:

• If you want a stable release right now, use v2.1.1.
• If you want newer features and fixes now, but will also want a stable release soon, check out the "release/v3.0" now and update it to the "v3.0" tag when the v3.0 final release comes out.
• If you're happy to live with potential issues, in exchange for faster fixes and early access to new features, check out "master" and update to the latest "master" whenever you feel it's worthwhile.