ESP32: Trying to build with the current IDF

I just received one of the ESP32-C3 demo boards and so I thought that I'd get my feet wet with the nodemcu/esp32 code. However, it looks as though the version of the IDF that we are using is quite old, and when I upgrade to the current master branch, nothing really works.

The base makefile in nodemcu-firmware doesn't actually build anything (once you have the idf installed and configured). Worse, I don't seem able to get the nodemcu components included. If I do make menuconfig then nodemcu shows up, but it doesn't appear to put anything useful into sdkconfig. If I do idf.py menuconfig then the nodemcu config doesn't even show up.

Is there anybody who understands the nodemcu/idf build system? Can it be made to work with the current idf master branch (or even the release/v4.3 branch)?

As we're on 3.x LTS (see #3196) I expect upgrading to 4.x will be quite a bit of work. In theory it should "just" be the list of breaking changes that came with https://github.com/espressif/esp-idf/releases/tag/v4.0 but surprises wouldn't surprise me.

Is there anybody who understands the nodemcu/idf build system?

At least @jmattsson should be familiar with it.

I recall Angus saying something about them switching from GNU make to cmake with the 4.0 release, so probably no compatibility whatsoever between those two releases. I'm woefully out of date on my knowledge and experience here though :/

I'm making progress by making random changes to things and have been having some success. I'm able to get some of nodemcu to build and it is mostly around weird include path problems that is hampering me at the moment.

On Thu, Feb 11, 2021 at 9:02 PM Johny Mattsson notifications@github.com wrote:

I recall Angus saying something about them switching from GNU make to cmake with the 4.0 release, so probably no compatibility whatsoever between those two releases. I'm woefully out of date on my knowledge and experience here though :/

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-777919371, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTIGNLU3VENTHQIYJRLS6SD4VANCNFSM4XOAOVRQ .

I have a branch pjsg:idf4 that is my work in progress if anyone is interested....

On Thu, Feb 11, 2021 at 9:56 PM Philip Gladstone philip@gladstonefamily.net wrote:

I'm making progress by making random changes to things and have been having some success. I'm able to get some of nodemcu to build and it is mostly around weird include path problems that is hampering me at the moment.

On Thu, Feb 11, 2021 at 9:02 PM Johny Mattsson notifications@github.com wrote:

I recall Angus saying something about them switching from GNU make to cmake with the 4.0 release, so probably no compatibility whatsoever between those two releases. I'm woefully out of date on my knowledge and experience here though :/

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-777919371, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTIGNLU3VENTHQIYJRLS6SD4VANCNFSM4XOAOVRQ .

I can get an image to build and I can flash it, but it doesn't work. Any ideas on how to debug this?

load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:15000 entry 0x40078630 [0;32mI (30) boot: ESP-IDF v3.1-dev-1381-g9a55b42f 2nd stage bootloader [0m [0;32mI (30) boot: compile time 18:01:16 [0m [0;32mI (30) boot: Enabling RNG early entropy source... [0m [0;32mI (36) boot: SPI Speed : 40MHz [0m [0;32mI (40) boot: SPI Mode : DIO [0m [0;32mI (44) boot: SPI Flash Size : 4MB [0m [0;32mI (48) boot: Partition Table: [0m [0;32mI (52) boot: ## Label Usage Type ST Offset Length [0m [0;32mI (59) boot: 0 nvs WiFi data 01 02 00009000 00006000 [0m [0;32mI (66) boot: 1 phy_init RF data 01 01 0000f000 00001000 [0m [0;32mI (74) boot: 2 factory factory app 00 00 00010000 00100000 [0m [0;32mI (81) boot: End of partition table [0m [0;32mI (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x109c8 ( 68040) map [0m [0;32mI (118) esp_image: segment 1: paddr=0x000209f0 vaddr=0x3ffb0000 size=0x02d34 ( 11572) load [0m [0;32mI (123) esp_image: segment 2: paddr=0x0002372c vaddr=0x40080000 size=0x0c8ec ( 51436) load [0m [0;32mI (146) esp_image: segment 3: paddr=0x00030020 vaddr=0x400d0020 size=0x41760 (268128) map [0m [0;32mI (241) esp_image: segment 4: paddr=0x00071788 vaddr=0x4008c8ec size=0x01040 ( 4160) load [0m [0;32mI (251) boot: Loaded app from partition at offset 0x10000 [0m [0;32mI (251) boot: Disabling RNG early entropy source... [0m

then nothing..... The link map shows that the app_main is being included....

Philip

On Thu, Feb 11, 2021 at 9:58 PM Philip Gladstone philip@gladstonefamily.net wrote:

I have a branch pjsg:idf4 that is my work in progress if anyone is interested....

On Thu, Feb 11, 2021 at 9:56 PM Philip Gladstone < philip@gladstonefamily.net> wrote:

I'm making progress by making random changes to things and have been having some success. I'm able to get some of nodemcu to build and it is mostly around weird include path problems that is hampering me at the moment.

On Thu, Feb 11, 2021 at 9:02 PM Johny Mattsson notifications@github.com wrote:

I recall Angus saying something about them switching from GNU make to cmake with the 4.0 release, so probably no compatibility whatsoever between those two releases. I'm woefully out of date on my knowledge and experience here though :/

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-777919371, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTIGNLU3VENTHQIYJRLS6SD4VANCNFSM4XOAOVRQ .

See if the gdbstub is alive. If you can hook in with gdb you should be able to make short work of the debugging. Docs e.g. https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-monitor.html

Failing that, try printf'ing your way through the start-up (that's what I normally end up doing).

If you're still not getting somewhere, modifying the bootloader to actually show the address it's jumping to when it thinks it's starting the app might be useful / give you a clue.

On Sun, 14 Feb 2021 at 11:24, Philip Gladstone notifications@github.com wrote:

I can get an image to build and I can flash it, but it doesn't work. Any ideas on how to debug this?

load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:15000 entry 0x40078630 [0;32mI (30) boot: ESP-IDF v3.1-dev-1381-g9a55b42f 2nd stage bootloader [0m [0;32mI (30) boot: compile time 18:01:16 [0m [0;32mI (30) boot: Enabling RNG early entropy source... [0m [0;32mI (36) boot: SPI Speed : 40MHz [0m [0;32mI (40) boot: SPI Mode : DIO [0m [0;32mI (44) boot: SPI Flash Size : 4MB [0m [0;32mI (48) boot: Partition Table: [0m [0;32mI (52) boot: ## Label Usage Type ST Offset Length [0m [0;32mI (59) boot: 0 nvs WiFi data 01 02 00009000 00006000 [0m [0;32mI (66) boot: 1 phy_init RF data 01 01 0000f000 00001000 [0m [0;32mI (74) boot: 2 factory factory app 00 00 00010000 00100000 [0m [0;32mI (81) boot: End of partition table [0m [0;32mI (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x109c8 ( 68040) map [0m [0;32mI (118) esp_image: segment 1: paddr=0x000209f0 vaddr=0x3ffb0000 size=0x02d34 ( 11572) load [0m [0;32mI (123) esp_image: segment 2: paddr=0x0002372c vaddr=0x40080000 size=0x0c8ec ( 51436) load [0m [0;32mI (146) esp_image: segment 3: paddr=0x00030020 vaddr=0x400d0020 size=0x41760 (268128) map [0m [0;32mI (241) esp_image: segment 4: paddr=0x00071788 vaddr=0x4008c8ec size=0x01040 ( 4160) load [0m [0;32mI (251) boot: Loaded app from partition at offset 0x10000 [0m [0;32mI (251) boot: Disabling RNG early entropy source... [0m

then nothing..... The link map shows that the app_main is being included....

Philip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-778698535, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGUJZZYMF74QBBYFS2MV4DS64J2TANCNFSM4XOAOVRQ .

I now have a version that boots on the esp32 with v4 of the IDF. I have a file system, and I have wifi (though not the net module).

W (144629) phy_init: failed to load RF calibration data (0x1102), falling
back to full calibration
I (144789) wifi:mode : sta (24:0a:c4:06:f4:f4)
I (144789) wifi:enable tsf
> I (144799) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1
I (145469) wifi:state: init -> auth (b0)
I (145479) wifi:state: auth -> assoc (0)
I (145479) wifi:state: assoc -> run (10)
I (145509) wifi:connected with Chateau Gladstone Guest, aid = 4, channel 1,
BW20, bssid = e2:63:da:7d:38:79
I (145509) wifi:security: WPA2-PSK, phy: bgn, rssi: -77
I (145509) wifi:pm start, type: 1

I (145589) wifi:AP's beacon interval = 102400 us, DTIM period = 3
W (145779) wifi:<ba-add>idx:0 (ifx:0, e2:63:da:7d:38:79), tid:0, ssn:1,
winSize:64
I (146779) esp_netif_handlers: sta ip: 192.168.103.140, mask:
255.255.255.0, gw: 192.168.103.1

However, the dev-esp32 branch is really old and I suspect that we really need to move to a much more common codebase.

Another issue is that the code size seems huge -- the nodemcu wifi module brings in maybe 400kb of code space and blew the 1MB code segment size. I actually switched to using -O2 and that brought it down somewhat. I can increase the partition size, but that seems wrong as well.

Anyway, my goal in all of this was to try and do the port to the esp32c3 which is (apparently) intended to be the new ESP8266 and come out at a similar price point. That task is up next, but at least I know that I have a roughly working codebase!

For those of you that haven't seen the new part, this is a side-by-side photo with a standard ESP32 dev board. It certainly could fit into a D1 Mini sized PCB. There is nothing on the underside of the new board and only silicon (as far as I can see) is the CP2104 USB/Serial interface, and some voltage regulators and what looks like a very small WS2812 -- but I have no idea what that part is.

[image: PXL_20210218_005422607.jpg] Philip

On Sat, Feb 13, 2021 at 10:22 PM Johny Mattsson notifications@github.com wrote:

See if the gdbstub is alive. If you can hook in with gdb you should be able to make short work of the debugging. Docs e.g.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-monitor.html

Failing that, try printf'ing your way through the start-up (that's what I normally end up doing).

If you're still not getting somewhere, modifying the bootloader to actually show the address it's jumping to when it thinks it's starting the app might be useful / give you a clue.

On Sun, 14 Feb 2021 at 11:24, Philip Gladstone notifications@github.com wrote:

I can get an image to build and I can flash it, but it doesn't work. Any ideas on how to debug this?

load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:15000 entry 0x40078630 [0;32mI (30) boot: ESP-IDF v3.1-dev-1381-g9a55b42f 2nd stage bootloader [0m [0;32mI (30) boot: compile time 18:01:16 [0m [0;32mI (30) boot: Enabling RNG early entropy source... [0m [0;32mI (36) boot: SPI Speed : 40MHz [0m [0;32mI (40) boot: SPI Mode : DIO [0m [0;32mI (44) boot: SPI Flash Size : 4MB [0m [0;32mI (48) boot: Partition Table: [0m [0;32mI (52) boot: ## Label Usage Type ST Offset Length [0m [0;32mI (59) boot: 0 nvs WiFi data 01 02 00009000 00006000 [0m [0;32mI (66) boot: 1 phy_init RF data 01 01 0000f000 00001000 [0m [0;32mI (74) boot: 2 factory factory app 00 00 00010000 00100000 [0m [0;32mI (81) boot: End of partition table [0m [0;32mI (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x109c8 ( 68040) map [0m [0;32mI (118) esp_image: segment 1: paddr=0x000209f0 vaddr=0x3ffb0000 size=0x02d34 ( 11572) load [0m [0;32mI (123) esp_image: segment 2: paddr=0x0002372c vaddr=0x40080000 size=0x0c8ec ( 51436) load [0m [0;32mI (146) esp_image: segment 3: paddr=0x00030020 vaddr=0x400d0020 size=0x41760 (268128) map [0m [0;32mI (241) esp_image: segment 4: paddr=0x00071788 vaddr=0x4008c8ec size=0x01040 ( 4160) load [0m [0;32mI (251) boot: Loaded app from partition at offset 0x10000 [0m [0;32mI (251) boot: Disabling RNG early entropy source... [0m

then nothing..... The link map shows that the app_main is being included....

Philip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-778698535 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAGUJZZYMF74QBBYFS2MV4DS64J2TANCNFSM4XOAOVRQ

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-778716439, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTKANOTITVMODCXFGGDS646XLANCNFSM4XOAOVRQ .

After ignoring all the warnings in the esp32-c3 build and disabling a bunch more modules, it boots:

 (60) boot_comm: chip revision: 2, min. bootloader chip revision: 0
I (67) boot.esp32c3: SPI Speed      : 80MHz
I (72) boot.esp32c3: SPI Mode       : DIO
I (77) boot.esp32c3: SPI Flash Size : 4MB
I (82) boot: Enabling RNG early entropy source...
I (87) boot: Partition Table:
I (91) boot: ## Label            Usage          Type ST Offset   Length
I (98) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (105) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (113) boot:  2 factory          factory app      00 00 00010000 00177000
I (120) boot:  3 node_spiffs      unknown          c2 00 00187000 00100000
I (128) boot: End of partition table
I (132) boot_comm: chip revision: 2, min. application chip revision: 0
I (139) esp_image: segment 0: paddr=00010020 vaddr=3c0e0020 size=252bch
(152252) map
I (172) esp_image: segment 1: paddr=000352e4 vaddr=3fc8f400 size=033c8h (
13256) load
I (175) esp_image: segment 2: paddr=000386b4 vaddr=40380000 size=07964h (
31076) load
I (183) esp_image: segment 3: paddr=00040020 vaddr=42000020 size=d1fe4h
(860132) map
I (320) esp_image: segment 4: paddr=0011200c vaddr=40387964 size=07994h (
31124) load
I (326) esp_image: segment 5: paddr=001199a8 vaddr=50000000 size=00004h (
  4) load
I (332) boot: Loaded app from partition at offset 0x10000
I (332) boot: Disabling RNG early entropy source...
I (349) cpu_start: Pro cpu up.
I (406) cpu_start: Pro cpu start user code
I (406) cpu_start: cpu freq: 160000000
I (406) cpu_start: Application information:
I (409) cpu_start: Project name:     nodemcu
I (414) cpu_start: App version:      1.4.0-master_20151229-779-g1459
I (421) cpu_start: Compile time:     Feb 17 2021 21:17:50
I (427) cpu_start: ELF file SHA256:  6450465877ed63d3...
I (433) cpu_start: ESP-IDF:          v4.4-dev-4-g73db14240-dirty
I (439) heap_init: Initializing. RAM available for dynamic allocation:
I (447) heap_init: At 3FC981E0 len 00027E20 (159 KiB): DRAM
I (453) heap_init: At 3FCC0000 len 0001F260 (124 KiB): STACK/DRAM
I (460) heap_init: At 50000004 len 00001FFC (7 KiB): FAKEDRAM
I (466) spi_flash: detected chip: generic
I (471) spi_flash: flash io: dio
I (475) cpu_start: Starting scheduler.
怘��������fx~x�������f��fx�fx�~fx����x��f��~����~������怘�怘����~�����~����f���fx��~f�xxff�������fx����fx�fx~f�~f��xff��~怘��ff�~�x��f�����f~�x��f�xf��f~�xx��f��fx�`f~�xx��x���`ff~�xx���f��ff~�x~�xx�xf�x`f~���xf~�x�x�x�x���f��xf~�xx��f��fxx����f~�xx��f��fxx���~�xx��f��fxx���f~�xx��f��fx`������x~��x~�xx��f��fx����~���f~�xx��f����~������~��~�x�f�`����x~�xx��f��fxf���x~���f~��f~���~���~���f~��f~��f~��f��~���`fx~�f�`��f`~����~ff~�xf`fx~��x��x�����fffff�~�����fxf�~�x�����ffff~��fxf�~���昀���f��`~���怘�f~������fx���f�~怘�xf��fx~`�x�x~�����xx���xx��f��fxx���x�x`f���xx��f�f�������x��x���xf��fxf~�x�x�x�x`�x�f`�xx��f�����x��xx��f��fxf�xx��f����`�xx��f��fx`���x����xf��fx~~�xx�x��`�x��~����x`f��x�`�x`���xx��x�x�x�x�x�f`���xf��fx�~�xf�x�xf�x�xx���xxf��f���xf��fx~x�xx��f��x�x���xx�xx��f��x����xff���xf��fx`~x`��xx��f�f�x��x~���xf��fxx~���xx��f������xx��f���������x�xx�����xf���x~x��fx�x�����xf���x~fffffffffffffff怘�xf���xf~�x~��x��xx���������xx���xf���x~~�f�����f�x~�����xx�x�x�x���xx���xf���x�~��xx�x~����~�x���x`�x`�xff`��fx��xxxff��������xxxf�������xf���x~�xxfx�fxxxfx�xx�x~����~fffxx�xx��f�f�x����xf���x`~f�xfx�f�xx��x�`��ff��x`�����xxx�`fx`x�xxxf�����x�xf���xx�xxx�`���怘�xf���xx~�x�x�x�x�xxfx�x�xfx�xxfxf�����x�x�xxx�xxfxf��������xf���~ff���xf��fx���xxfx�fxxxfx�xf���~���xxx�������fx��fx�xxfxxxf���xf��x~�xf�x�x����x�xxfxxxf��f�x���fx������fx`�xf�x�x~���f`�xx��x�xf������x`�����xf���~f�x��xf�x�xxf����x��ffxx��x�xx�x��fff�����xf�xx��ff�������xf��~�x�x����f�����xf�x~�������xxx�������fx��fx怘�xf���~�xf�x�x�xx�xxf�xf�����xxxx�xx�xx�xf���xff���xxfx���xf��~f�xf�����xx���xx�xx�x�xx�xx�xx�xx�xfxx�xx�xx�xx���x���xf�x~�xx�x��x�xxx��������x�xx�������x�f��x~��x�xxx`���x怘�xf�x~x`�������x���

But doesn't work.....😣

On Wed, Feb 17, 2021 at 8:03 PM Philip Gladstone philip@gladstonefamily.net wrote:

I now have a version that boots on the esp32 with v4 of the IDF. I have a file system, and I have wifi (though not the net module).
W (144629) phy_init: failed to load RF calibration data (0x1102), falling
back to full calibration
I (144789) wifi:mode : sta (24:0a:c4:06:f4:f4)
I (144789) wifi:enable tsf
> I (144799) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1
I (145469) wifi:state: init -> auth (b0)
I (145479) wifi:state: auth -> assoc (0)
I (145479) wifi:state: assoc -> run (10)
I (145509) wifi:connected with Chateau Gladstone Guest, aid = 4, channel
1, BW20, bssid = e2:63:da:7d:38:79
I (145509) wifi:security: WPA2-PSK, phy: bgn, rssi: -77
I (145509) wifi:pm start, type: 1

I (145589) wifi:AP's beacon interval = 102400 us, DTIM period = 3
W (145779) wifi:<ba-add>idx:0 (ifx:0, e2:63:da:7d:38:79), tid:0, ssn:1,
winSize:64
I (146779) esp_netif_handlers: sta ip: 192.168.103.140, mask:
255.255.255.0, gw: 192.168.103.1
However, the dev-esp32 branch is really old and I suspect that we really need to move to a much more common codebase.

Another issue is that the code size seems huge -- the nodemcu wifi module brings in maybe 400kb of code space and blew the 1MB code segment size. I actually switched to using -O2 and that brought it down somewhat. I can increase the partition size, but that seems wrong as well.

Anyway, my goal in all of this was to try and do the port to the esp32c3 which is (apparently) intended to be the new ESP8266 and come out at a similar price point. That task is up next, but at least I know that I have a roughly working codebase!

For those of you that haven't seen the new part, this is a side-by-side photo with a standard ESP32 dev board. It certainly could fit into a D1 Mini sized PCB. There is nothing on the underside of the new board and only silicon (as far as I can see) is the CP2104 USB/Serial interface, and some voltage regulators and what looks like a very small WS2812 -- but I have no idea what that part is.

[image: PXL_20210218_005422607.jpg] Philip

On Sat, Feb 13, 2021 at 10:22 PM Johny Mattsson notifications@github.com wrote:

See if the gdbstub is alive. If you can hook in with gdb you should be able to make short work of the debugging. Docs e.g.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-monitor.html

Failing that, try printf'ing your way through the start-up (that's what I normally end up doing).

If you're still not getting somewhere, modifying the bootloader to actually show the address it's jumping to when it thinks it's starting the app might be useful / give you a clue.

On Sun, 14 Feb 2021 at 11:24, Philip Gladstone notifications@github.com wrote:

I can get an image to build and I can flash it, but it doesn't work. Any ideas on how to debug this?

load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:15000 entry 0x40078630 [0;32mI (30) boot: ESP-IDF v3.1-dev-1381-g9a55b42f 2nd stage bootloader [0m [0;32mI (30) boot: compile time 18:01:16 [0m [0;32mI (30) boot: Enabling RNG early entropy source... [0m [0;32mI (36) boot: SPI Speed : 40MHz [0m [0;32mI (40) boot: SPI Mode : DIO [0m [0;32mI (44) boot: SPI Flash Size : 4MB [0m [0;32mI (48) boot: Partition Table: [0m [0;32mI (52) boot: ## Label Usage Type ST Offset Length [0m [0;32mI (59) boot: 0 nvs WiFi data 01 02 00009000 00006000 [0m [0;32mI (66) boot: 1 phy_init RF data 01 01 0000f000 00001000 [0m [0;32mI (74) boot: 2 factory factory app 00 00 00010000 00100000 [0m [0;32mI (81) boot: End of partition table [0m [0;32mI (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x109c8 ( 68040) map [0m [0;32mI (118) esp_image: segment 1: paddr=0x000209f0 vaddr=0x3ffb0000 size=0x02d34 ( 11572) load [0m [0;32mI (123) esp_image: segment 2: paddr=0x0002372c vaddr=0x40080000 size=0x0c8ec ( 51436) load [0m [0;32mI (146) esp_image: segment 3: paddr=0x00030020 vaddr=0x400d0020 size=0x41760 (268128) map [0m [0;32mI (241) esp_image: segment 4: paddr=0x00071788 vaddr=0x4008c8ec size=0x01040 ( 4160) load [0m [0;32mI (251) boot: Loaded app from partition at offset 0x10000 [0m [0;32mI (251) boot: Disabling RNG early entropy source... [0m

then nothing..... The link map shows that the app_main is being included....

Philip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-778698535 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAGUJZZYMF74QBBYFS2MV4DS64J2TANCNFSM4XOAOVRQ

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-778716439, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTKANOTITVMODCXFGGDS646XLANCNFSM4XOAOVRQ .

Any success on this? or you have dropped this idea? Mainly thinking about ESP32-S2 but have no idea how and if at all ...

I stopped at this stage. I need to see if Espressif added the support into the IDF that we needed to get the linking to work. If so, then it ought to be possible to build a very limited subset of modules with the current IDF. I never tried building for the 8266, so I don't know if that would be viable.

On Tue, May 25, 2021 at 1:37 PM Modestas Bunokas @.***> wrote:

Any success on this? or you have dropped this idea? Mainly thinking about ESP32-S2 but have no idea how and if at all ...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-848077193, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTLUN32N6HR6YUX7HC3TPPN5RANCNFSM4XOAOVRQ .

I'm hoping I'll be able to spend some time bringing the ESP32 branch up to the latest IDF in the near future. I'm guessing the smartest thing would be to start from your idf4 branch, @pjsg?

I would certainly take a look there. It is fairly hacked up and doesn't build most of nodemcu, but it built enough to get to a prompt. I don't know whether espressif ever fixed the linker issue...

On Thu, Jul 8, 2021, 03:36 Johny Mattsson @.***> wrote:

I'm hoping I'll be able to spend some time bringing the ESP32 branch up to the latest IDF in the near future. I'm guessing the smartest thing would be to start from your idf4 branch, @pjsg https://github.com/pjsg?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nodemcu/nodemcu-firmware/issues/3397#issuecomment-876067464, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTOCZV6VCRJJCHKQPVTTWUDJPANCNFSM4XOAOVRQ .

I've just been going through the latest IDF documentation, and it looks like there's enough stuff in the linker fragment support to make things work now. I'll have to switch from our current null-terminated lists over to known-size arrays, but that should be easy enough.

I've also had a look through your branch, and if you're okay with it I think it'll be easier for me to start clean off dev-esp32 and then borrow heavily on a file-by-file or snippet-by-snippet basis so I can dodge the C3 stuff for now. I just don't want you to think I'd be doing it to steal your thunder - it certainly looks like you've done a great chunk of the heavy lifting already! :)

As long as $work doesn't give me new priorities I'm hoping to get onto this next week.

I'm fine with you starting again. I didn't really know what I was doing when I started. It didn't take me long to get to the stage that I got to. I'd start again as well!

Okay, so I've started this, but have now hit a bit of a snag. The new linker fragments support appears to only be available on the master branch and not v4.4-dev or earlier, and said master branch is not currently in a buildable state it seems (issue in newlib/locks.c). I'll see if I can find a workaround and/or work my way backwards to hopefully find a sweet spot where both things work.

Say @igrr, I don't suppose you have an estimate on when the nice KEEP()/ALIGN()/SURROUND() support is going to arrive on a named branch?

@jmattsson for the master branch you probably need to run install.sh, . ./export.sh and then idf.py fullclean — this is because the toolchain has recently been updated from esp-2020r3 to esp-2021r1. The build errors in locks.c you observe will disappear then.

We will create release/v4.4 around the end of August, and aim to release v4.4 around November.

@igrr Ah, thank you for those pointers, that saved me some hours of troubleshooting! I'm now back to dealing with my own issues instead 🤣 And much obliged with the release estimates! The new ld fragments support should make my life considerably easier going forward, once I've tamed the transition.

Okay, I believe I have this almost fully in the bag now over on this branch. What do people think of me pushing this to a (temporary) dev-esp32-idf4 branch under the nodemcu org for better exposure/testing? I'd be reluctant to PR this right away, since it's a significant change and there are a few changes which break backwards compatibility. Do we have any highly visible release notes somewhere that should also be updated? (Sorry, I've been out of the loop for too long)

@jpeletier I haven't touched the "extmod" stuff yet, since I've never used it and am thus not quite sure of usage / best way forward to migrate from the 3.x IDF build structure to the 4.x IDF for those. I'd welcome your (and others') input here.

@igrr In the end it wasn't possible to move everything over to _seg_start/_seg_end symbol usage, so I've done "something clever" to get the zero-termination happening, which I'm hoping won't turn out to be fragile, but if you'd consider a feature request to add a linker fragment option of e.g. APPEND_LONGS(n, val) to facilitate easier placement of zeroes after a SURROUND() block that would be welcome :)

What do people think of me pushing this to a (temporary) dev-esp32-idf4 branch under the nodemcu org for better exposure/testing?

By all means, go ahead!

Do we have any highly visible release notes somewhere

We only write release notes for master (erg.. release) drops. Hence, we've never had ESP32 releases. However, I'm sure people would appreciate up-to-date docs (what works, what doesn't) in the IDF 4 branch. If it won't mean too much work for me I could even make that branch available in the cloud builder. Maybe my existing scripts work out of the box?

Thanks @marcelstoer.

Okay, there's now a dev-esp32-idf4 branch here too :) The docs in this branch have been updated, so where there was once a function there is now a note saying it has been removed due to underlying functionality disappearing upstream. It could be nice to those items listed somewhere explicitly so people can come forewarned rather than find out once their code throws an error. I don't know where might be a good place for that. Suggestions welcome.

Your cloud builder scripts would need some tweaking to cope with the new things. make defconfig was removed, but you can probably replace it with cp sdkconfig.defaults sdkconfig. There's a new ./install.sh script which has to be run first, which chains through to the IDF's install.sh script automatically. Oh, and cmake needs to be available on the build host. If you're building in a directory where you previously had IDF 3.x, you'll also need to find . -name *.pyc | xargs rm to clean up interfering precompiled python things. And MORE_CFLAGS is no longer a thing. The integer-only build is an option in the sdkconfig now instead.

Oh, and I'd carefully updated the travis build script, only to discover that TravisCI.org is now fully gone. Do we have plans to migrate to something else, and if so what? (Somewhat tangential to the rest of the discussion, but...)

extmod

@jmattsson, drop this for now, I need to see the community demand to port this forward before dedicating effort, if it is only me I see no point yet. Thank you for your work on this, looks great btw

@pjsg I've also ordered myself a couple of C3 dev boards so I can start looking at that in a few weeks hopefully. We have some Xtensa-only assembler over in the lua component that we'll need to #ifdef properly now that we get RISC-V in the mix.

It could be nice to those items listed somewhere explicitly so people can come forewarned rather than find out once their code throws an error.

Absolutely. Add a chapter/paragraph to docs entry page?

Your cloud builder scripts would need some tweaking to cope with the new things.

Thanks for the analysis. I don't see me having the capacity to look after that for the moment. However, by the time we want to merge your work back to the dev-esp32 branch I would have to have it ready.

Btw, the cloud builder runs in a GitHub CI pipeline.

TravisCI.org is now fully gone. Do we have plans to migrate to something else

@HHHartmann migrated the non-ESP32 braches from Travis to GitHub CI half a year ago: https://github.com/nodemcu/nodemcu-firmware/commits/release/.github/workflows. However, at the time he left the .travis.yml untouched as the service was still available.

Thanks, I'll have a look at the github workflows then! I'm also thinking that it might be nice to branch off dev-esp32 to a dev-esp32-idf3-legacy branch to give people a better chance to migrate as we hop onto idf4 for main dev. Thoughts?

Any chance of using LUA 5.3 or later like https://github.com/UncleRus/esp-idf-lua? Just a stupid question, have no idea how complicated it could be. For me ESP32-S2 with SPIRAM looks ideal for LUA, but after getting hands dirty with ESP8266 and LUA 5.3 I would like to go with ESP32-S2 and LUA 5.3 or 5.4.x

Thank you

@KT819GM That is definitely on the cards. We're wanting to get to the point where we have a shared branch for both the ESP8226 and ESP32 so we can have as many features shared across both platforms as possible, including the new Lua version.

The path to get there is a bit challenging, seeing as we're still using the "non-OS" SDK on the ESP8266 which is very different from the RTOS & IDF on the ESP32 side. I'm hoping that now that $work has a desire for some of the features only available on the RTOS version in the 8266 SDK that I'll get some time to dedicate to this again. I had hoped to have had the branches merged well over a year ago, but then life & work & world circumstances changed 😩

I'm also thinking that it might be nice to branch off dev-esp32 to a dev-esp32-idf3-legacy

That might make sense once your IDF 4 branch is sufficiently stable. Just let me know when you're ready so I can adjust the cloud builder such that at least that legacy branch is still supported.

Any chance of using LUA 5.3 or later like https://github.com/UncleRus/esp-idf-lua

OT: Lua is not an acronym 😉 I can't assess the quality of that project but if someone is familiar with IDF and Lua then maybe she/he could be convinced to join forces with us?

Okay I've switched this branch over to github actions. The workflow is not as full-featured as on the esp8266 branch, but it's matching what the old travis build was doing at least. I've also fixed a couple of issues I found, and done a code-cleanup to sort out most of the warnings (the luac.cross build is still giving off a bunch, I may or may not investigate those).

We're slowly starting to test the idf4 stuff at $work, but that will only cover the parts we actually use, so everyone, please do dig in and tell me where I b0rked the upgrade :)

Okay, I took care of the luac.cross warnings too.

My ESP32C3 boards have arrived. I'm hoping to be able to push coexisting C3 & regular ESP32 support within a day or two (much thanks to @pjsg's existing work on getting the C3 up and running).

Alright, I've pushed the C3 stuff. I don't think I've broken anything... :D

@jmattsson should we lock the dev-esp32 branch to avoid nasty merge conflicts?

I've heard worse ideas. If others are cool with it, that would certainly make life easier.

I'm currently working on bringing over Lua 5.3 from the 8266 branch, fwiw.

@KT819GM Well, it turned out that getting the 5.1+5.3 work from the ESP8266 branch over to the ESP32 branch was a lot more work than I had expected, to the tune of over a week's worth of evening effort. That said, I've got it all going in a branch over here if you want to try it out. I need to go over the docs and see what needs updating there before I push to the main repo, but that's a job for another night.

Hi, I would happily test it, but at home somehow I have only ESP32-S2 available and: When trying to build it fails on the CAN module which is disabled on a menuconfig. if I set target for ESP32 build is successful, but I have no live unit to try. Checked sdkconfig to make sure that CAN is disabled. In any case t.y. for your hard work, if you could look at the build issue and could tell me how to avoid CAN module I would try to build and flash it onto device.

About build process itself - not sure who done this, but it's straight forward on Ubuntu 20.04 in three steps (four if need to apt install cmake) in total, so perfectly doable on WSL on windows (just did that).

error itself with idf.py set-target esp32-s2:

In file included from /home/mode/esp/nodemcu-firmware/sdk/esp32-esp-idf/components/soc/esp32s2/include/soc/dport_reg.h:33,
                 from /home/mode/esp/nodemcu-firmware/components/driver_can/CAN.c:36:
/home/mode/esp/nodemcu-firmware/components/driver_can/CAN.c: In function 'CAN_init':
/home/mode/esp/nodemcu-firmware/components/driver_can/CAN.c:163:53: error: 'DPORT_CAN_CLK_EN' undeclared (first use in this function); did you mean 'DPORT_RMT_CLK_EN'?
     DPORT_SET_PERI_REG_MASK(DPORT_PERIP_CLK_EN_REG, DPORT_CAN_CLK_EN);
                                                     ^~~~~~~~~~~~~~~~
/home/mode/esp/nodemcu-firmware/sdk/esp32-esp-idf/components/soc/esp32s2/include/soc/dport_access.h:76:88: note: in definition of macro '_DPORT_WRITE_PERI_REG'
 #define _DPORT_WRITE_PERI_REG(addr, val) (*((volatile uint32_t *)(addr))) = (uint32_t)(val)
                                                                                        ^~~
/home/mode/esp/nodemcu-firmware/sdk/esp32-esp-idf/components/soc/esp32s2/include/soc/dport_access.h:89:46: note: in expansion of macro 'DPORT_WRITE_PERI_REG'
 #define DPORT_SET_PERI_REG_MASK(reg, mask)   DPORT_WRITE_PERI_REG((reg), (DPORT_READ_PERI_REG(reg)|(mask)))
                                              ^~~~~~~~~~~~~~~~~~~~
/home/mode/esp/nodemcu-firmware/components/driver_can/CAN.c:163:5: note: in expansion of macro 'DPORT_SET_PERI_REG_MASK'
     DPORT_SET_PERI_REG_MASK(DPORT_PERIP_CLK_EN_REG, DPORT_CAN_CLK_EN);
     ^~~~~~~~~~~~~~~~~~~~~~~
/home/mode/esp/nodemcu-firmware/components/driver_can/CAN.c:163:53: note: each undeclared identifier is reported only once for each function it appears in
     DPORT_SET_PERI_REG_MASK(DPORT_PERIP_CLK_EN_REG, DPORT_CAN_CLK_EN);
                                                     ^~~~~~~~~~~~~~~~
/home/mode/esp/nodemcu-firmware/sdk/esp32-esp-idf/components/soc/esp32s2/include/soc/dport_access.h:76:88: note: in definition of macro '_DPORT_WRITE_PERI_REG'
 #define _DPORT_WRITE_PERI_REG(addr, val) (*((volatile uint32_t *)(addr))) = (uint32_t)(val)
                                                                                        ^~~
/home/mode/esp/nodemcu-firmware/sdk/esp32-esp-idf/components/soc/esp32s2/include/soc/dport_access.h:89:46: note: in expansion of macro 'DPORT_WRITE_PERI_REG'
 #define DPORT_SET_PERI_REG_MASK(reg, mask)   DPORT_WRITE_PERI_REG((reg), (DPORT_READ_PERI_REG(reg)|(mask)))
                                              ^~~~~~~~~~~~~~~~~~~~
/home/mode/esp/nodemcu-firmware/components/driver_can/CAN.c:163:5: note: in expansion of macro 'DPORT_SET_PERI_REG_MASK'
     DPORT_SET_PERI_REG_MASK(DPORT_PERIP_CLK_EN_REG, DPORT_CAN_CLK_EN);
     ^~~~~~~~~~~~~~~~~~~~~~~
/home/mode/esp/nodemcu-firmware/components/driver_can/CAN.c:164:55: error: 'DPORT_CAN_RST' undeclared (first use in this function); did you mean 'DPORT_WDG_RST'?
     DPORT_CLEAR_PERI_REG_MASK(DPORT_PERIP_RST_EN_REG, DPORT_CAN_RST);
                                                       ^~~~~~~~~~~~~
/home/mode/esp/nodemcu-firmware/sdk/esp32-esp-idf/components/soc/esp32s2/include/soc/dport_access.h:76:88: note: in definition of macro '_DPORT_WRITE_PERI_REG'
 #define _DPORT_WRITE_PERI_REG(addr, val) (*((volatile uint32_t *)(addr))) = (uint32_t)(val)
                                                                                        ^~~
/home/mode/esp/nodemcu-firmware/sdk/esp32-esp-idf/components/soc/esp32s2/include/soc/dport_access.h:86:46: note: in expansion of macro 'DPORT_WRITE_PERI_REG'
 #define DPORT_CLEAR_PERI_REG_MASK(reg, mask) DPORT_WRITE_PERI_REG((reg), (DPORT_READ_PERI_REG(reg)&(~(mask))))
                                              ^~~~~~~~~~~~~~~~~~~~
/home/mode/esp/nodemcu-firmware/components/driver_can/CAN.c:164:5: note: in expansion of macro 'DPORT_CLEAR_PERI_REG_MASK'
     DPORT_CLEAR_PERI_REG_MASK(DPORT_PERIP_RST_EN_REG, DPORT_CAN_RST);
     ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/mode/esp/nodemcu-firmware/components/driver_can/CAN.c:168:39: error: 'CAN_TX_IDX' undeclared (first use in this function); did you mean 'TWAI_TX_IDX'?
     gpio_matrix_out(CAN_cfg.tx_pin_id,CAN_TX_IDX,0,0);
                                       ^~~~~~~~~~
                                       TWAI_TX_IDX
/home/mode/esp/nodemcu-firmware/components/driver_can/CAN.c:173:35: error: 'CAN_RX_IDX' undeclared (first use in this function); did you mean 'TWAI_RX_IDX'?
  gpio_matrix_in(CAN_cfg.rx_pin_id,CAN_RX_IDX,0);
                                   ^~~~~~~~~~
                                   TWAI_RX_IDX
/home/mode/esp/nodemcu-firmware/components/driver_can/CAN.c:228:20: error: 'ETS_CAN_INTR_SOURCE' undeclared (first use in this function)
     esp_intr_alloc(ETS_CAN_INTR_SOURCE,0,CAN_isr,NULL,NULL);
                    ^~~~~~~~~~~~~~~~~~~
make[3]: *** [esp-idf/driver_can/CMakeFiles/__idf_driver_can.dir/build.make:63: esp-idf/driver_can/CMakeFiles/__idf_driver_can.dir/CAN.c.obj] Error 1
make[3]: Leaving directory '/home/mode/esp/nodemcu-firmware/build'
make[2]: *** [CMakeFiles/Makefile2:5840: esp-idf/driver_can/CMakeFiles/__idf_driver_can.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....

@jmattsson thanks a lot for your hard work! As this thread is quite long already I was wondering whether it's more effective to discuss Lua 5.3 on ESP32 in a separate issue or whether that'd be more distracting as IDF 4 and Lua 5.3 are going to land in the same PR (towards dev-esp32) anyway.

@KT819GM Hey thanks for pointing that out! I had not realised the S2/S3 had different peripherals. I've reworked the modules/driver handling, so it should build on my branch now.

@marcelstoer Yeah I think this is all sufficiently big that a "big bang" approach is the only sensible way to do it now. I think I'm still of the view that a rename of our existing dev-esp32 to dev-esp32-legacy and swap the dev-esp32-idf4 into its place is going to be the least insane thing. I've done the docs, and I've sorted out the S2/S3 issues, so I'm tempted to merge my dev-esp32-idf4-lua53 branch onto dev-esp32-idf4 here again. I'm not aware of any regressions from my porting of the Lua 5.1+5.3 stuff, so I think it's ready. A second view/opinion certainly appreciated.

I still want to have a look at the VFS stuff before we do any cut-over though. By now it feels we might be suffering from using our own VFS implementation over the Espressif/IDF provided one. Switching over would allow for more regular POSIX type code, which wouldn't be a bad thing. Plus any IDF components which use the filesystem would actually find files where they expect them...

@jmattsson Hi, I've tried with updated branch, now I'm up to this point:

NodeMCU ESP32 build unspecified powered by Lua 5.3.5 on IDF v4.4-dev-1849-g8e3e65a47b
cannot open init.lua: 
> print("hello")
Guru Meditation Error: Core  0 panic'ed (Memory protection fault).

With debug enabled could get bit more info, sadly not usable for me:

NodeMCU ESP32 build unspecified powered by Lua 5.3.5 on IDF v4.4-dev-1849-g8e3e65a47b
cannot open init.lua: 
> print("hello")
Guru Meditation Error: Core  0 panic'ed (Memory protection fault). 
abort() was called at PC 0x40026de3 on core 0
abort() was called at PC 0x40026de3 on core 0
abort() was called at PC 0x40026de3 on core 0
Backtrace:0x40026b0d:0x3fd90560 |<-CORRUPTED
ELF file SHA256: 5c9f801ce5737c8b

I've disabled SPI RAM, not used LFS and in general any activity in the terminal (pressing enter on a empty field) will force panic. Full startup header with bootloader messages (SPI RAM enabled):

ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3ffe6100,len:0x212c
load:0x4004c000,len:0xb88
load:0x40050000,len:0x2fec
entry 0x4004c234
[1B][0;32mI (21) boot: ESP-IDF v4.4-dev-1849-g8e3e65a47b 2nd stage bootloader[1B][0m
[1B][0;32mI (21) boot: compile time 19:46:59[1B][0m
D (21) bootloader_flash: mmu set block paddr=0x00000000 (was 0xffffffff)[1B][0m
[1B][0;32mI (29) boot: chip revision: 0[1B][0m
D (33) boot.esp32s2: magic e9[1B][0m
D (35) boot.esp32s2: segments 03[1B][0m
D (39) boot.esp32s2: spi_mode 02[1B][0m
D (42) boot.esp32s2: spi_speed 0f[1B][0m
D (45) boot.esp32s2: spi_size 02[1B][0m
[1B][0;32mI (49) boot.esp32s2: SPI Speed      : 80MHz[1B][0m
[1B][0;32mI (53) boot.esp32s2: SPI Mode       : DIO[1B][0m
[1B][0;32mI (58) boot.esp32s2: SPI Flash Size : 4MB[1B][0m
D (63) boot: Enabling RTCWDT(9000 ms)[1B][0m
[1B][0;32mI (66) boot: Enabling RNG early entropy source...[1B][0m
D (72) bootloader_flash: mmu set paddr=00000000 count=1 size=c00 src_addr=8000 src_addr_aligned=0[1B][0m
D (81) boot: mapped partition table 0x8000 at 0x3f008000[1B][0m
D (86) flash_parts: partition table verified, 6 entries[1B][0m
[1B][0;32mI (91) boot: Partition Table:[1B][0m
[1B][0;32mI (95) boot: ## Label            Usage          Type ST Offset   Length[1B][0m
D (102) boot: load partition table entry 0x3f008000[1B][0m
D (107) boot: type=1 subtype=2[1B][0m
[1B][0;32mI (110) boot:  0 nvs              WiFi data        01 02 00009000 00006000[1B][0m
D (118) boot: load partition table entry 0x3f008020[1B][0m
D (123) boot: type=1 subtype=1[1B][0m
[1B][0;32mI (126) boot:  1 phy_init         RF data          01 01 0000f000 00001000[1B][0m
D (134) boot: load partition table entry 0x3f008040[1B][0m
D (139) boot: type=0 subtype=0[1B][0m
[1B][0;32mI (142) boot:  2 factory          factory app      00 00 00010000 00180000[1B][0m
D (149) boot: load partition table entry 0x3f008060[1B][0m
D (154) boot: type=c2 subtype=1[1B][0m
[1B][0;32mI (157) boot:  3 lfs              unknown          c2 01 00190000 00010000[1B][0m
D (165) boot: load partition table entry 0x3f008080[1B][0m
D (170) boot: type=c2 subtype=0[1B][0m
[1B][0;32mI (173) boot:  4 nodemcuspiffs    unknown          c2 00 001a0000 00070000[1B][0m
[1B][0;32mI (181) boot: End of partition table[1B][0m
D (185) boot: Trying partition index -1 offs 0x10000 size 0x180000[1B][0m
D (191) esp_image: reading image header @ 0x10000[1B][0m
D (196) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)[1B][0m
D (203) esp_image: image header: 0xe9 0x07 0x02 0x02 400254a8[1B][0m
V (209) esp_image: loading segment header 0 at offset 0x10018[1B][0m
V (214) esp_image: segment data length 0x301e8 data starts 0x10020[1B][0m
V (221) esp_image: segment 0 map_segment 1 segment_data_offs 0x10020 load_addr 0x3f000020[1B][0m
[1B][0;32mI (229) esp_image: segment 0: paddr=00010020 vaddr=3f000020 size=301e8h (197096) map[1B][0m
D (237) esp_image: free data page_count 0x0000003f[1B][0m
D (242) bootloader_flash: mmu set paddr=00010000 count=4 size=301e8 src_addr=10020 src_addr_aligned=10000[1B][0m
V (291) esp_image: loading segment header 1 at offset 0x40208[1B][0m
D (291) bootloader_flash: mmu set block paddr=0x00040000 (was 0xffffffff)[1B][0m
V (293) esp_image: segment data length 0x3330 data starts 0x40210[1B][0m
V (299) esp_image: segment 1 map_segment 0 segment_data_offs 0x40210 load_addr 0x3ffca0e0[1B][0m
[1B][0;32mI (307) esp_image: segment 1: paddr=00040210 vaddr=3ffca0e0 size=03330h ( 13104) load[1B][0m
D (316) esp_image: free data page_count 0x0000003f[1B][0m
D (321) bootloader_flash: mmu set paddr=00040000 count=1 size=3330 src_addr=40210 src_addr_aligned=40000[1B][0m
V (333) esp_image: loading segment header 2 at offset 0x43540[1B][0m
D (336) bootloader_flash: mmu set block paddr=0x00040000 (was 0xffffffff)[1B][0m
V (343) esp_image: segment data length 0xcad0 data starts 0x43548[1B][0m
V (349) esp_image: segment 2 map_segment 0 segment_data_offs 0x43548 load_addr 0x40024000[1B][0m
[1B][0;32mI (357) esp_image: segment 2: paddr=00043548 vaddr=40024000 size=0cad0h ( 51920) load[1B][0m
D (366) esp_image: free data page_count 0x0000003f[1B][0m
D (371) bootloader_flash: mmu set paddr=00040000 count=2 size=cad0 src_addr=43548 src_addr_aligned=40000[1B][0m
V (393) esp_image: loading segment header 3 at offset 0x50018[1B][0m
D (393) bootloader_flash: mmu set block paddr=0x00050000 (was 0xffffffff)[1B][0m
V (395) esp_image: segment data length 0xc0744 data starts 0x50020[1B][0m
V (401) esp_image: segment 3 map_segment 1 segment_data_offs 0x50020 load_addr 0x40080020[1B][0m
[1B][0;32mI (409) esp_image: segment 3: paddr=00050020 vaddr=40080020 size=c0744h (788292) map[1B][0m
D (418) esp_image: free data page_count 0x0000003f[1B][0m
D (423) bootloader_flash: mmu set paddr=00050000 count=13 size=c0744 src_addr=50020 src_addr_aligned=50000[1B][0m
V (590) esp_image: loading segment header 4 at offset 0x110764[1B][0m
D (590) bootloader_flash: mmu set block paddr=0x00110000 (was 0xffffffff)[1B][0m
V (591) esp_image: segment data length 0x960c data starts 0x11076c[1B][0m
V (597) esp_image: segment 4 map_segment 0 segment_data_offs 0x11076c load_addr 0x40030ad0[1B][0m
[1B][0;32mI (606) esp_image: segment 4: paddr=0011076c vaddr=40030ad0 size=0960ch ( 38412) load[1B][0m
D (614) esp_image: free data page_count 0x0000003f[1B][0m
D (619) bootloader_flash: mmu set paddr=00110000 count=1 size=960c src_addr=11076c src_addr_aligned=110000[1B][0m
V (639) esp_image: loading segment header 5 at offset 0x119d78[1B][0m
D (639) bootloader_flash: mmu set block paddr=0x00110000 (was 0xffffffff)[1B][0m
V (642) esp_image: segment data length 0x2c data starts 0x119d80[1B][0m
V (648) esp_image: segment 5 map_segment 0 segment_data_offs 0x119d80 load_addr 0x40070000[1B][0m
[1B][0;32mI (656) esp_image: segment 5: paddr=00119d80 vaddr=40070000 size=0002ch (    44) load[1B][0m
D (665) esp_image: free data page_count 0x0000003f[1B][0m
D (669) bootloader_flash: mmu set paddr=00110000 count=1 size=2c src_addr=119d80 src_addr_aligned=110000[1B][0m
V (679) esp_image: loading segment header 6 at offset 0x119dac[1B][0m
D (685) bootloader_flash: mmu set block paddr=0x00110000 (was 0xffffffff)[1B][0m
V (692) esp_image: segment data length 0x10 data starts 0x119db4[1B][0m
V (698) esp_image: segment 6 map_segment 0 segment_data_offs 0x119db4 load_addr 0x50000800[1B][0m
[1B][0;32mI (706) esp_image: segment 6: paddr=00119db4 vaddr=50000800 size=00010h (    16) load[1B][0m
D (715) esp_image: free data page_count 0x0000003f[1B][0m
D (719) bootloader_flash: mmu set paddr=00110000 count=1 size=10 src_addr=119db4 src_addr_aligned=110000[1B][0m
V (729) esp_image: image start 0x00010000 end of last section 0x00119dc4[1B][0m
D (736) bootloader_flash: mmu set block paddr=0x00110000 (was 0xffffffff)[1B][0m
D (743) boot: Calculated hash: a62dce9b15a63ea4d56e15b91477fd0e53eb44b37ddda777ec1c272e2c285549[1B][0m
[1B][0;32mI (762) boot: Loaded app from partition at offset 0x10000[1B][0m
[1B][0;32mI (762) boot: Disabling RNG early entropy source...[1B][0m
D (763) boot: Mapping segment 0 as DROM[1B][0m
D (767) boot: Mapping segment 3 as IROM[1B][0m
D (771) boot: calling set_cache_and_start_app[1B][0m
D (775) boot: configure drom and irom and start[1B][0m
V (780) boot: d mmu set paddr=00010000 vaddr=3f000000 size=197096 n=4[1B][0m
V (786) boot: rc=0[1B][0m
V (788) boot: i mmu set paddr=00050000 vaddr=40080000 size=788292 n=13[1B][0m
V (795) boot: rc=0[1B][0m
D (797) boot: start: 0x400254a8[1B][0m
[1B][0;32mI (812) cache: Instruction cache  : size 8KB, 4Ways, cache line size 32Byte[1B][0m
[1B][0;32mI (812) cache: Data cache         : size 8KB, 4Ways, cache line size 32Byte[1B][0m
[1B][0;32mI (817) spiram: Found 16MBit SPI RAM device[1B][0m
[1B][0;32mI (822) spiram: SPI RAM mode: sram 40m[1B][0m
[1B][0;32mI (827) spiram: PSRAM initialized, cache is in normal (1-core) mode.[1B][0m
[1B][0;32mI (834) cpu_start: Pro cpu up.[1B][0m
[1B][0;32mI (1248) spй[18]ffћ[18][06]f¤љI[05]5Ѓmemory test OK[1B][0m
D (1248) efuse: In EFUSE_BLK2__DATA4_REG is used 3 bits starting with 4 bit[1B][0m
D (1257) clk: RTC_SLOW_CLK calibration value: 5672118[1B][0m
[1B][0;32mI (1265) cpu_start: Pro cpu start user code[1B][0m
[1B][0;32mI (1265) cpu_start: cpu freq: 160000000[1B][0m
[1B][0;32mI (1265) cpu_start: Application information:[1B][0m
[1B][0;32mI (1270) cpu_start: Project name:     nodemcu[1B][0m
[1B][0;32mI (1275) cpu_start: App version:      tmr-libmain-binpatch150-783-g3a[1B][0m
[1B][0;32mI (1282) cpu_start: Compile time:     Aug 22 2021 20:00:41[1B][0m
[1B][0;32mI (1288) cpu_start: ELF file SHA256:  95aa96bced6d5b95...[1B][0m
[1B][0;32mI (1294) cpu_start: ESP-IDF:          v4.4-dev-1849-g8e3e65a47b[1B][0m
D (1301) memory_layout: Checking 5 reserved memory ranges:[1B][0m
D (1306) memory_layout: Reserved memory range 0x3f500000 - 0x3ff80000[1B][0m
D (1313) memory_layout: Reserved memory range 0x3ff9e000 - 0x3ff9e02c[1B][0m
D (1319) memory_layout: Reserved memory range 0x3ffb4000 - 0x3ffca0dc[1B][0m
D (1326) memory_layout: Reserved memory range 0x3ffca0e0 - 0x3ffd20b8[1B][0m
D (1332) memory_layout: Reserved memory range 0x3ffffa10 - 0x40000000[1B][0m
D (1339) memory_layout: Building list of available memory regions:[1B][0m
D (1345) memory_layout: Available memory region 0x3ff9e02c - 0x3ffa0000[1B][0m
D (1352) memory_layout: Available memory region 0x3ffd20b8 - 0x3ffd4000[1B][0m
D (1359) memory_layout: Available memory region 0x3ffd4000 - 0x3ffd8000[1B][0m
D (1365) memory_layout: Available memory region 0x3ffd8000 - 0x3ffdc000[1B][0m
D (1372) memory_layout: Available memory region 0x3ffdc000 - 0x3ffe0000[1B][0m
D (1379) memory_layout: Available memory region 0x3ffe0000 - 0x3ffe4000[1B][0m
D (1385) memory_layout: Available memory region 0x3ffe4000 - 0x3ffe8000[1B][0m
D (1392) memory_layout: Available memory region 0x3ffe8000 - 0x3ffec000[1B][0m
D (1399) memory_layout: Available memory region 0x3ffec000 - 0x3fff0000[1B][0m
D (1405) memory_layout: Available memory region 0x3fff0000 - 0x3fff4000[1B][0m
D (1412) memory_layout: Available memory region 0x3fff4000 - 0x3fff8000[1B][0m
D (1419) memory_layout: Available memory region 0x3fff8000 - 0x3fffc000[1B][0m
D (1425) memory_layout: Available memory region 0x3fffc000 - 0x3ffffa10[1B][0m
[1B][0;32mI (1432) heap_init: Initializing. RAM available for dynamic allocation:[1B][0m
D (1439) heap_init: New heap initialised at 0x3ff9e02c[1B][0m
[1B][0;32mI (1445) heap_init: At 3FF9E02C len 00001FD4 (7 KiB): RTCRAM[1B][0m
D (1451) heap_init: New heap initialised at 0x3ffd20b8[1B][0m
[1B][0;32mI (1456) heap_init: At 3FFD20B8 len 00029F48 (167 KiB): DRAM[1B][0m
[1B][0;32mI (1462) heap_init: At 3FFFC000 len 00003A10 (14 KiB): DRAM[1B][0m
[1B][0;32mI (1469) spiram: Adding pool of 2048K of external SPI memory to heap allocator[1B][0m
D (1477) FLASH_HAL: extra_dummy: 0[1B][0m
D (1480) spi_flash: trying chip: issi[1B][0m
D (1484) spi_flash: trying chip: gd[1B][0m
D (1488) spi_flash: trying chip: mxic[1B][0m
D (1491) spi_flash: trying chip: winbond[1B][0m
D (1495) spi_flash: trying chip: boya[1B][0m
D (1499) spi_flash: trying chip: generic[1B][0m
[1B][0;32mI (1503) spi_flash: detected chip: generic[1B][0m
[1B][0;32mI (1508) spi_flash: flash io: dio[1B][0m
D (1512) cpu_start: calling init function: 0x40121688[1B][0m
D (1517) cpu_start: calling init function: 0x4012131c[1B][0m
D (1522) cpu_start: calling init function: 0x401211d4[1B][0m
D (1527) cpu_start: calling init function: 0x40120fb4[1B][0m
D (1532) cpu_start: calling init function: 0x400f1b50[1B][0m
D (1537) cpu_start: calling init function: 0x400da8a4[1B][0m
D (1542) efuse: In EFUSE_BLK2__DATA4_REG is used 3 bits starting with 4 bit[1B][0m
D (1553) ADC: Calib(V1) ADC1 atten=3: 06C1[1B][0m
D (1554) cpu_start: calling init function: 0x400be06c[1B][0m
D (1559) cpu_start: calling init function: 0x40083498[1B][0m
D (1564) intr_alloc: Connected src 73 to int 10 (cpu 0)[1B][0m
D (1569) intr_alloc: Connected src 28 to int 2 (cpu 0)[1B][0m
[1B][0;32mI (1574) cpu_start: Starting scheduler on PRO CPU.[1B][0m
D (1580) heap_init: New heap initialised at 0x3fffc000[1B][0m
[1B][0;32mI (1580) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations[1B][0m
D (1590) intr_alloc: Connected src 17 to int 3 (cpu 0)[1B][0m
D (1590) event: running task for loop 0x3ff9feb0[1B][0m
D (1600) event: created task for loop 0x3ff9feb0[1B][0m
D (1600) event: created event loop 0x3ff9feb0[1B][0m
D (1620) intr_alloc: Connected src 37 to int 9 (cpu 0)[1B][0m
[1B][0;31mE (1620) uart: call uart_driver_install API first[1B][0m

Mounting flash filesystem...
mount res: 0, 0
D (1640) partition: Loading the partition table[1B][0m
D (1640) partition: Partition table MD5 verified[1B][0m
D (1650) esp_netif_lwip: LwIP stack has been initialized[1B][0m
D (1650) esp_netif_lwip: esp-netif has been successfully initialized[1B][0m
Task task_lua started.
D (1650) nvs: nvs_open_from_partition lfsload 0[1B][0m
D (1660) nvs: nvs_open_from_partition lfsload 0[1B][0m
D (1670) intr_alloc: Connected src 23 to int 12 (cpu 0)[1B][0m
D (1670) esp_netif_objects: esp_netif_add_to_list 0x3ffe0718[1B][0m
D (1670) esp_netif_objects: esp_netif_add_to_list netif added successfully (total netifs: 1)[1B][0m
D (1680) esp_netif_objects: esp_netif_add_to_list 0x3ffe0c84[1B][0m
D (1690) esp_netif_objects: esp_netif_add_to_list netif added successfully (total netifs: 2)[1B][0m
D (1700) nvs: nvs_open_from_partition misc 1[1B][0m
D (1700) nvs: nvs_get_str_or_blob log[1B][0m
I (1720) wifi:wifi driver task: 3ffdaac8, prio:23, stack:6656, core=0
[1B][0;32mI (1720) system_api: Base MAC address is not set[1B][0m
[1B][0;32mI (1720) system_api: read default base MAC address from EFUSE[1B][0m
D (1720) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 8 bit[1B][0m
D (1730) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 0 bit[1B][0m
D (1740) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 24 bit[1B][0m
D (1740) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 16 bit[1B][0m
D (1750) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 8 bit[1B][0m
D (1760) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 0 bit[1B][0m
D (1770) nvs: nvs_open_from_partition nvs.net80211 1[1B][0m
D (1770) nvs: nvs_get opmode 1[1B][0m
D (1770) nvs: nvs_get_str_or_blob sta.ssid[1B][0m
D (1780) nvs: nvs_get sta.authmode 1[1B][0m
D (1780) nvs: nvs_get_str_or_blob sta.pswd[1B][0m
D (1790) nvs: nvs_get_str_or_blob sta.pmk[1B][0m
D (1790) nvs: nvs_get sta.chan 1[1B][0m
D (1790) nvs: nvs_get auto.conn 1[1B][0m
D (1800) nvs: nvs_get bssid.set 1[1B][0m
D (1800) nvs: nvs_get_str_or_blob sta.bssid[1B][0m
D (1800) nvs: nvs_get sta.lis_intval 2[1B][0m
D (1810) nvs: nvs_get sta.phym 1[1B][0m
D (1810) nvs: nvs_get sta.phybw 1[1B][0m
D (1820) nvs: nvs_get_str_or_blob sta.apsw[1B][0m
D (1820) nvs: nvs_get_str_or_blob sta.apinfo[1B][0m
D (1820) nvs: nvs_get sta.scan_method 1[1B][0m
D (1830) nvs: nvs_get sta.sort_method 1[1B][0m
D (1830) nvs: nvs_get sta.minrssi 1[1B][0m
D (1840) nvs: nvs_get sta.minauth 1[1B][0m
D (1840) nvs: nvs_get sta.pmf_e 1[1B][0m
D (1840) nvs: nvs_get sta.pmf_r 1[1B][0m
D (1850) nvs: nvs_get sta.btm_e 1[1B][0m
D (1850) nvs: nvs_get sta.rrm_e 1[1B][0m
D (1850) nvs: nvs_get_str_or_blob ap.ssid[1B][0m
D (1860) nvs: nvs_get_str_or_blob ap.passwd[1B][0m
D (1860) nvs: nvs_get_str_or_blob ap.pmk[1B][0m
D (1860) nvs: nvs_get ap.chan 1[1B][0m
D (1870) nvs: nvs_get ap.authmode 1[1B][0m
D (1870) nvs: nvs_get ap.hidden 1[1B][0m
D (1870) nvs: nvs_get ap.max.conn 1[1B][0m
D (1880) nvs: nvs_get bcn.interval 2[1B][0m
D (1880) nvs: nvs_get ap.phym 1[1B][0m
D (1890) nvs: nvs_get ap.phybw 1[1B][0m
D (1890) nvs: nvs_get ap.sndchan 1[1B][0m
D (1890) nvs: nvs_get ap.pmf_e 1[1B][0m
D (1900) nvs: nvs_get ap.pmf_r 1[1B][0m
D (1900) nvs: nvs_get ap.p_cipher 1[1B][0m
D (1900) nvs: nvs_get lorate 1[1B][0m
D (1910) nvs: nvs_get_str_or_blob country[1B][0m
D (1910) nvs: nvs_get ap.ftm_r 1[1B][0m
D (1910) nvs: nvs_set ap.sndchan 1 1[1B][0m
I (1920) wifi:wifi firmware version: ff5f4ea
I (1920) wifi:wifi certification version: v7.0
I (1920) wifi:config NVS flash: enabled
I (1930) wifi:config nano formating: disabled
I (1930) wifi:Init data frame dynamic rx buffer num: 32
I (1940) wifi:Init management frame dynamic rx buffer num: 32
I (1940) wifi:Init management short buffer num: 32
I (1950) wifi:Init static tx buffer num: 16
I (1950) wifi:Init tx cache buffer num: 32
I (1950) wifi:Init static rx buffer size: 1600
I (1960) wifi:Init static rx buffer num: 10
I (1960) wifi:Init dynamic rx buffer num: 32
[1B][0;32mI (1970) wifi_init: rx ba win: 6[1B][0m
[1B][0;32mI (1970) wifi_init: tcpip mbox: 32[1B][0m
[1B][0;32mI (1970) wifi_init: udp mbox: 6[1B][0m
[1B][0;32mI (1980) wifi_init: tcp mbox: 6[1B][0m
[1B][0;32mI (1980) wifi_init: tcp tx win: 5744[1B][0m
[1B][0;32mI (1990) wifi_init: tcp rx win: 5744[1B][0m
[1B][0;32mI (1990) wifi_init: tcp mss: 1440[1B][0m
[1B][0;32mI (1990) wifi_init: WiFi IRAM OP enabled[1B][0m
[1B][0;32mI (2000) wifi_init: WiFi RX IRAM OP enabled[1B][0m

NodeMCU ESP32 build unspecified powered by Lua 5.3.5 on IDF v4.4-dev-1849-g8e3e65a47b
cannot open init.lua:

Thank you

I'm still of the view that a rename of our existing dev-esp32 to dev-esp32-legacy and swap the dev-esp32-idf4 into its place is going to be the least insane thing.

All fine for me. In accordance with our 1.5.4.1-final we could also call it dev-esp32-idf3-final to express that it's effectively frozen/unmaintained/etc. I need to make a few small adjustments to the Docker image in the cloud builder to support building from that IDF3 branch after the name change. So, I appreciate it if we can coordinate this to avoid disruptions.

I've done the docs, and I've sorted out the S2/S3 issues, so I'm tempted to merge my dev-esp32-idf4-lua53 branch onto dev-esp32-idf4 here again.

Fine for me.

@KT819GM Hmm, that's weird. I am unable to reproduce that here on my ESP32 and ESP32C3 boards. Looking at that startup log though, it looks like the external SPI RAM is still active? spiram: Adding pool of 2048K of external SPI memory to heap allocator. What board are you using? I might need to get myself an ESP32S2 so I can track this down...

Memory protection fault

On ESP32-S2 and later, this means that the program has either tried to write to memory which is used for code storage, or tried to execute from memory used for data storage. I'm not sure if this is something NodeMCU might be doing on purpose, or is a simple out-of-bounds memory access.

I will take ESP32 home today to try on the same dev. environment and will come back here with results. Log which I've posted with bootloader messages was with psram enabled (I've noted that before log 🙃) but in general I have tested with and without psram with same results.

@KT819GM I may have gotten part-way to something that can help work out what's going on with your S2. I discovered that Lua panic handling on the console was broken, and have now pushed a fix for that. I've also swapped from our old console UART driver to the regular IDF UART driver. I'm hoping at least one of these will mean we get something more informative when it crashes...

@igrr Any chance of not having the IDF UART driver refuse to install when the panic-to-gdb-stub option is enabled? Removing that check made my make monitor -> automatic gdb session work just fine.

Edit: Also I just ordered an ESP32-S2 dev board with SPI RAM for myself so I can get to the bottom of this little mystery.

Ok, so I'm not too fast as @jmattsson so did not even tried ESP32. Pulled latest commit and result is:

ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3ffe6100,len:0x212c
load:0x4004c000,len:0xb88
load:0x40050000,len:0x2fec
entry 0x4004c234
[1B][0;32mI (21) boot: ESP-IDF v4.4-dev-1849-g8e3e65a47b 2nd stage bootloader[1B][0m
[1B][0;32mI (21) boot: compile time 19:46:59[1B][0m
D (21) bootloader_flash: mmu set block paddr=0x00000000 (was 0xffffffff)[1B][0m
[1B][0;32mI (29) boot: chip revision: 0[1B][0m
D (32) boot.esp32s2: magic e9[1B][0m
D (35) boot.esp32s2: segments 03[1B][0m
D (39) boot.esp32s2: spi_mode 02[1B][0m
D (42) boot.esp32s2: spi_speed 0f[1B][0m
D (45) boot.esp32s2: spi_size 02[1B][0m
[1B][0;32mI (49) boot.esp32s2: SPI Speed      : 80MHz[1B][0m
[1B][0;32mI (53) boot.esp32s2: SPI Mode       : DIO[1B][0m
[1B][0;32mI (58) boot.esp32s2: SPI Flash Size : 4MB[1B][0m
D (63) boot: Enabling RTCWDT(9000 ms)[1B][0m
[1B][0;32mI (66) boot: Enabling RNG early entropy source...[1B][0m
D (72) bootloader_flash: mmu set paddr=00000000 count=1 size=c00 src_addr=8000 src_addr_aligned=0[1B][0m
D (81) boot: mapped partition table 0x8000 at 0x3f008000[1B][0m
D (86) flash_parts: partition table verified, 6 entries[1B][0m
[1B][0;32mI (91) boot: Partition Table:[1B][0m
[1B][0;32mI (95) boot: ## Label            Usage          Type ST Offset   Length[1B][0m
D (102) boot: load partition table entry 0x3f008000[1B][0m
D (107) boot: type=1 subtype=2[1B][0m
[1B][0;32mI (110) boot:  0 nvs              WiFi data        01 02 00009000 00006000[1B][0m
D (118) boot: load partition table entry 0x3f008020[1B][0m
D (123) boot: type=1 subtype=1[1B][0m
[1B][0;32mI (126) boot:  1 phy_init         RF data          01 01 0000f000 00001000[1B][0m
D (134) boot: load partition table entry 0x3f008040[1B][0m
D (139) boot: type=0 subtype=0[1B][0m
[1B][0;32mI (142) boot:  2 factory          factory app      00 00 00010000 00180000[1B][0m
D (149) boot: load partition table entry 0x3f008060[1B][0m
D (154) boot: type=c2 subtype=1[1B][0m
[1B][0;32mI (157) boot:  3 lfs              unknown          c2 01 00190000 00010000[1B][0m
D (165) boot: load partition table entry 0x3f008080[1B][0m
D (170) boot: type=c2 subtype=0[1B][0m
[1B][0;32mI (173) boot:  4 nodemcuspiffs    unknown          c2 00 001a0000 00070000[1B][0m
[1B][0;32mI (181) boot: End of partition table[1B][0m
D (185) boot: Trying partition index -1 offs 0x10000 size 0x180000[1B][0m
D (191) esp_image: reading image header @ 0x10000[1B][0m
D (196) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)[1B][0m
D (203) esp_image: image header: 0xe9 0x07 0x02 0x02 400254a8[1B][0m
V (209) esp_image: loading segment header 0 at offset 0x10018[1B][0m
V (214) esp_image: segment data length 0x2f820 data starts 0x10020[1B][0m
V (221) esp_image: segment 0 map_segment 1 segment_data_offs 0x10020 load_addr 0x3f000020[1B][0m
[1B][0;32mI (229) esp_image: segment 0: paddr=00010020 vaddr=3f000020 size=2f820h (194592) map[1B][0m
D (237) esp_image: free data page_count 0x0000003f[1B][0m
D (242) bootloader_flash: mmu set paddr=00010000 count=3 size=2f820 src_addr=10020 src_addr_aligned=10000[1B][0m
V (291) esp_image: loading segment header 1 at offset 0x3f840[1B][0m
D (291) bootloader_flash: mmu set block paddr=0x00030000 (was 0xffffffff)[1B][0m
V (292) esp_image: segment data length 0x7d0 data starts 0x3f848[1B][0m
V (298) esp_image: segment 1 map_segment 0 segment_data_offs 0x3f848 load_addr 0x3ffca0e0[1B][0m
[1B][0;32mI (307) esp_image: segment 1: paddr=0003f848 vaddr=3ffca0e0 size=007d0h (  2000) load[1B][0m
D (315) esp_image: free data page_count 0x0000003f[1B][0m
D (320) bootloader_flash: mmu set paddr=00030000 count=2 size=7d0 src_addr=3f848 src_addr_aligned=30000[1B][0m
V (330) esp_image: loading segment header 2 at offset 0x40018[1B][0m
D (335) bootloader_flash: mmu set block paddr=0x00040000 (was 0xffffffff)[1B][0m
V (342) esp_image: segment data length 0xbd828 data starts 0x40020[1B][0m
V (348) esp_image: segment 2 map_segment 1 segment_data_offs 0x40020 load_addr 0x40080020[1B][0m
[1B][0;32mI (357) esp_image: segment 2: paddr=00040020 vaddr=40080020 size=bd828h (776232) map[1B][0m
D (365) esp_image: free data page_count 0x0000003f[1B][0m
D (370) bootloader_flash: mmu set paddr=00040000 count=12 size=bd828 src_addr=40020 src_addr_aligned=40000[1B][0m
V (534) esp_image: loading segment header 3 at offset 0xfd848[1B][0m
D (534) bootloader_flash: mmu set block paddr=0x000f0000 (was 0xffffffff)[1B][0m
V (536) esp_image: segment data length 0x2b60 data starts 0xfd850[1B][0m
V (542) esp_image: segment 3 map_segment 0 segment_data_offs 0xfd850 load_addr 0x3ffca8b0[1B][0m
[1B][0;32mI (550) esp_image: segment 3: paddr=000fd850 vaddr=3ffca8b0 size=02b60h ( 11104) load[1B][0m
D (559) esp_image: free data page_count 0x0000003f[1B][0m
D (564) bootloader_flash: mmu set paddr=000f0000 count=2 size=2b60 src_addr=fd850 src_addr_aligned=f0000[1B][0m
V (576) esp_image: loading segment header 4 at offset 0x1003b0[1B][0m
D (579) bootloader_flash: mmu set block paddr=0x00100000 (was 0xffffffff)[1B][0m
V (586) esp_image: segment data length 0x160dc data starts 0x1003b8[1B][0m
V (592) esp_image: segment 4 map_segment 0 segment_data_offs 0x1003b8 load_addr 0x40024000[1B][0m
[1B][0;32mI (601) esp_image: segment 4: paddr=001003b8 vaddr=40024000 size=160dch ( 90332) load[1B][0m
D (609) esp_image: free data page_count 0x0000003f[1B][0m
D (614) bootloader_flash: mmu set paddr=00100000 count=2 size=160dc src_addr=1003b8 src_addr_aligned=100000[1B][0m
V (646) esp_image: loading segment header 5 at offset 0x116494[1B][0m
D (647) bootloader_flash: mmu set block paddr=0x00110000 (was 0xffffffff)[1B][0m
V (648) esp_image: segment data length 0x2c data starts 0x11649c[1B][0m
V (654) esp_image: segment 5 map_segment 0 segment_data_offs 0x11649c load_addr 0x40070000[1B][0m
[1B][0;32mI (662) esp_image: segment 5: paddr=0011649c vaddr=40070000 size=0002ch (    44) load[1B][0m
D (671) esp_image: free data page_count 0x0000003f[1B][0m
D (676) bootloader_flash: mmu set paddr=00110000 count=1 size=2c src_addr=11649c src_addr_aligned=110000[1B][0m
V (685) esp_image: loading segment header 6 at offset 0x1164c8[1B][0m
D (691) bootloader_flash: mmu set block paddr=0x00110000 (was 0xffffffff)[1B][0m
V (698) esp_image: segment data length 0x10 data starts 0x1164d0[1B][0m
V (704) esp_image: segment 6 map_segment 0 segment_data_offs 0x1164d0 load_addr 0x50000800[1B][0m
[1B][0;32mI (712) esp_image: segment 6: paddr=001164d0 vaddr=50000800 size=00010h (    16) load[1B][0m
D (721) esp_image: free data page_count 0x0000003f[1B][0m
D (726) bootloader_flash: mmu set paddr=00110000 count=1 size=10 src_addr=1164d0 src_addr_aligned=110000[1B][0m
V (735) esp_image: image start 0x00010000 end of last section 0x001164e0[1B][0m
D (742) bootloader_flash: mmu set block paddr=0x00110000 (was 0xffffffff)[1B][0m
D (749) boot: Calculated hash: dd26a3c0496519541fd6623ad2e55ae047c760ba52a6b2e334f275852e9a9612[1B][0m
[1B][0;32mI (768) boot: Loaded app from partition at offset 0x10000[1B][0m
[1B][0;32mI (768) boot: Disabling RNG early entropy source...[1B][0m
D (769) boot: Mapping segment 0 as DROM[1B][0m
D (773) boot: Mapping segment 2 as IROM[1B][0m
D (777) boot: calling set_cache_and_start_app[1B][0m
D (782) boot: configure drom and irom and start[1B][0m
V (786) boot: d mmu set paddr=00010000 vaddr=3f000000 size=194592 n=3[1B][0m
V (793) boot: rc=0[1B][0m
V (795) boot: i mmu set paddr=00040000 vaddr=40080000 size=776232 n=12[1B][0m
V (801) boot: rc=0[1B][0m
D (803) boot: start: 0x400254a8[1B][0m
[1B][0;32mI (818) cache: Instruction cache  : size 8KB, 4Ways, cache line size 32Byte[1B][0m
[1B][0;32mI (818) cache: Data cache         : size 8KB, 4Ways, cache line size 32Byte[1B][0m
[1B][0;32mI (824) spiram: Found 16MBit SPI RAM device[1B][0m
[1B][0;32mI (829) spiram: SPI RAM mode: sram 40m[1B][0m
[1B][0;32mI (833) spiram: PSRAM initialized, cache is in normal (1-core) mode.[1B][0m
[1B][0;32mI (840) cpu_start: Pro cpu up.[1B][0m
[1B][0;32mI (1254) sp™†шffћ[18][06]*
љI[05]5Ѓmemory test OK[1B][0m
D (1254) efuse: In EFUSE_BLK2__DATA4_REG is used 3 bits starting with 4 bit[1B][0m
D (1263) clk: RTC_SLOW_CLK calibration value: 5658988[1B][0m
[1B][0;32mI (1271) cpu_start: Pro cpu start user code[1B][0m
[1B][0;32mI (1271) cpu_start: cpu freq: 160000000[1B][0m
[1B][0;32mI (1271) cpu_start: Application information:[1B][0m
[1B][0;32mI (1276) cpu_start: Project name:     nodemcu[1B][0m
[1B][0;32mI (1281) cpu_start: App version:      tmr-libmain-binpatch150-785-g46[1B][0m
[1B][0;32mI (1288) cpu_start: Compile time:     Aug 23 2021 16:52:14[1B][0m
[1B][0;32mI (1295) cpu_start: ELF file SHA256:  62bd306a110b2e44...[1B][0m
[1B][0;32mI (1301) cpu_start: ESP-IDF:          v4.4-dev-1849-g8e3e65a47b[1B][0m
D (1307) memory_layout: Checking 5 reserved memory ranges:[1B][0m
D (1313) memory_layout: Reserved memory range 0x3f500000 - 0x3ff80000[1B][0m
D (1319) memory_layout: Reserved memory range 0x3ff9e000 - 0x3ff9e02c[1B][0m
D (1326) memory_layout: Reserved memory range 0x3ffb4000 - 0x3ffca0dc[1B][0m
D (1332) memory_layout: Reserved memory range 0x3ffca0e0 - 0x3ffd20a0[1B][0m
D (1339) memory_layout: Reserved memory range 0x3ffffa10 - 0x40000000[1B][0m
D (1345) memory_layout: Building list of available memory regions:[1B][0m
D (1352) memory_layout: Available memory region 0x3ff9e02c - 0x3ffa0000[1B][0m
D (1358) memory_layout: Available memory region 0x3ffd20a0 - 0x3ffd4000[1B][0m
D (1365) memory_layout: Available memory region 0x3ffd4000 - 0x3ffd8000[1B][0m
D (1372) memory_layout: Available memory region 0x3ffd8000 - 0x3ffdc000[1B][0m
D (1378) memory_layout: Available memory region 0x3ffdc000 - 0x3ffe0000[1B][0m
D (1385) memory_layout: Available memory region 0x3ffe0000 - 0x3ffe4000[1B][0m
D (1392) memory_layout: Available memory region 0x3ffe4000 - 0x3ffe8000[1B][0m
D (1398) memory_layout: Available memory region 0x3ffe8000 - 0x3ffec000[1B][0m
D (1405) memory_layout: Available memory region 0x3ffec000 - 0x3fff0000[1B][0m
D (1412) memory_layout: Available memory region 0x3fff0000 - 0x3fff4000[1B][0m
D (1418) memory_layout: Available memory region 0x3fff4000 - 0x3fff8000[1B][0m
D (1425) memory_layout: Available memory region 0x3fff8000 - 0x3fffc000[1B][0m
D (1432) memory_layout: Available memory region 0x3fffc000 - 0x3ffffa10[1B][0m
[1B][0;32mI (1438) heap_init: Initializing. RAM available for dynamic allocation:[1B][0m
D (1446) heap_init: New heap initialised at 0x3ff9e02c[1B][0m
[1B][0;32mI (1451) heap_init: At 3FF9E02C len 00001FD4 (7 KiB): RTCRAM[1B][0m
D (1457) heap_init: New heap initialised at 0x3ffd20a0[1B][0m
[1B][0;32mI (1463) heap_init: At 3FFD20A0 len 00029F60 (167 KiB): DRAM[1B][0m
[1B][0;32mI (1469) heap_init: At 3FFFC000 len 00003A10 (14 KiB): DRAM[1B][0m
[1B][0;32mI (1475) spiram: Adding pool of 2048K of external SPI memory to heap allocator[1B][0m
D (1483) FLASH_HAL: extra_dummy: 0[1B][0m
D (1487) spi_flash: trying chip: issi[1B][0m
D (1490) spi_flash: trying chip: gd[1B][0m
D (1494) spi_flash: trying chip: mxic[1B][0m
D (1498) spi_flash: trying chip: winbond[1B][0m
D (1502) spi_flash: trying chip: boya[1B][0m
D (1505) spi_flash: trying chip: generic[1B][0m
[1B][0;32mI (1509) spi_flash: detected chip: generic[1B][0m
[1B][0;32mI (1514) spi_flash: flash io: dio[1B][0m
D (1518) cpu_start: calling init function: 0x4011f64c[1B][0m
D (1523) cpu_start: calling init function: 0x4011f2e0[1B][0m
D (1528) cpu_start: calling init function: 0x4011f198[1B][0m
D (1533) cpu_start: calling init function: 0x4011ef78[1B][0m
D (1538) cpu_start: calling init function: 0x400efc04[1B][0m
D (1544) cpu_start: calling init function: 0x400d8958[1B][0m
D (1549) efuse: In EFUSE_BLK2__DATA4_REG is used 3 bits starting with 4 bit[1B][0m
D (1559) ADC: Calib(V1) ADC1 atten=3: 06C2[1B][0m
D (1560) cpu_start: calling init function: 0x400bc33c[1B][0m
D (1565) cpu_start: calling init function: 0x400835a4[1B][0m
D (1570) intr_alloc: Connected src 73 to int 10 (cpu 0)[1B][0m
D (1576) intr_alloc: Connected src 28 to int 2 (cpu 0)[1B][0m
[1B][0;32mI (1581) cpu_start: Starting scheduler on PRO CPU.[1B][0m
D (1586) heap_init: New heap initialised at 0x3fffc000[1B][0m
[1B][0;32mI (1586) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations[1B][0m
D (1596) intr_alloc: Connected src 17 to int 3 (cpu 0)[1B][0m
D (1596) event: running task for loop 0x3ff9feb0[1B][0m
D (1606) event: created task for loop 0x3ff9feb0[1B][0m
D (1606) event: created event loop 0x3ff9feb0[1B][0m
[1B][0;32mI (1616) uart: queue free spaces: 3[1B][0m
D (1616) intr_alloc: Connected src 37 to int 9 (cpu 0)[1B][0m

Mounting flash filesystem...
mount res: 0, 0
D (1636) partition: Loading the partition table[1B][0m
D (1636) partition: Partition table MD5 verified[1B][0m
D (1646) esp_netif_lwip: LwIP stack has been initialized[1B][0m
D (1646) esp_netif_lwip: esp-netif has been successfully initialized[1B][0m
Task task_lua started.
D (1646) nvs: nvs_open_from_partition lfsload 0[1B][0m
D (1656) nvs: nvs_open_from_partition lfsload 0[1B][0m
D (1666) intr_alloc: Connected src 23 to int 12 (cpu 0)[1B][0m
D (1666) esp_netif_objects: esp_netif_add_to_list 0x3ffe0b68[1B][0m
D (1666) esp_netif_objects: esp_netif_add_to_list netif added successfully (total netifs: 1)[1B][0m
D (1676) esp_netif_objects: esp_netif_add_to_list 0x3ffe10b0[1B][0m
D (1686) esp_netif_objects: esp_netif_add_to_list netif added successfully (total netifs: 2)[1B][0m
D (1696) nvs: nvs_open_from_partition misc 1[1B][0m
D (1696) nvs: nvs_get_str_or_blob log[1B][0m
I (1716) wifi:wifi driver task: 3ffdb520, prio:23, stack:6656, core=0
[1B][0;32mI (1716) system_api: Base MAC address is not set[1B][0m
[1B][0;32mI (1716) system_api: read default base MAC address from EFUSE[1B][0m
D (1716) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 8 bit[1B][0m
D (1726) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 0 bit[1B][0m
D (1736) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 24 bit[1B][0m
D (1736) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 16 bit[1B][0m
D (1746) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 8 bit[1B][0m
D (1756) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 0 bit[1B][0m
D (1766) nvs: nvs_open_from_partition nvs.net80211 1[1B][0m
D (1766) nvs: nvs_get opmode 1[1B][0m
D (1766) nvs: nvs_get_str_or_blob sta.ssid[1B][0m
D (1776) nvs: nvs_get sta.authmode 1[1B][0m
D (1776) nvs: nvs_get_str_or_blob sta.pswd[1B][0m
D (1786) nvs: nvs_get_str_or_blob sta.pmk[1B][0m
D (1786) nvs: nvs_get sta.chan 1[1B][0m
D (1786) nvs: nvs_get auto.conn 1[1B][0m
D (1796) nvs: nvs_get bssid.set 1[1B][0m
D (1796) nvs: nvs_get_str_or_blob sta.bssid[1B][0m
D (1796) nvs: nvs_get sta.lis_intval 2[1B][0m
D (1806) nvs: nvs_get sta.phym 1[1B][0m
D (1806) nvs: nvs_get sta.phybw 1[1B][0m
D (1806) nvs: nvs_get_str_or_blob sta.apsw[1B][0m
D (1816) nvs: nvs_get_str_or_blob sta.apinfo[1B][0m
D (1816) nvs: nvs_get sta.scan_method 1[1B][0m
D (1826) nvs: nvs_get sta.sort_method 1[1B][0m
D (1826) nvs: nvs_get sta.minrssi 1[1B][0m
D (1826) nvs: nvs_get sta.minauth 1[1B][0m
D (1836) nvs: nvs_get sta.pmf_e 1[1B][0m
D (1836) nvs: nvs_get sta.pmf_r 1[1B][0m
D (1846) nvs: nvs_get sta.btm_e 1[1B][0m
D (1846) nvs: nvs_get sta.rrm_e 1[1B][0m
D (1846) nvs: nvs_get_str_or_blob ap.ssid[1B][0m
D (1856) nvs: nvs_get_str_or_blob ap.passwd[1B][0m
D (1856) nvs: nvs_get_str_or_blob ap.pmk[1B][0m
D (1856) nvs: nvs_get ap.chan 1[1B][0m
D (1866) nvs: nvs_get ap.authmode 1[1B][0m
D (1866) nvs: nvs_get ap.hidden 1[1B][0m
D (1866) nvs: nvs_get ap.max.conn 1[1B][0m
D (1876) nvs: nvs_get bcn.interval 2[1B][0m
D (1876) nvs: nvs_get ap.phym 1[1B][0m
D (1876) nvs: nvs_get ap.phybw 1[1B][0m
D (1886) nvs: nvs_get ap.sndchan 1[1B][0m
D (1886) nvs: nvs_get ap.pmf_e 1[1B][0m
D (1886) nvs: nvs_get ap.pmf_r 1[1B][0m
D (1896) nvs: nvs_get ap.p_cipher 1[1B][0m
D (1896) nvs: nvs_get lorate 1[1B][0m
D (1896) nvs: nvs_get_str_or_blob country[1B][0m
D (1906) nvs: nvs_get ap.ftm_r 1[1B][0m
D (1906) nvs: nvs_set ap.sndchan 1 1[1B][0m
I (1916) wifi:wifi firmware version: ff5f4ea
I (1916) wifi:wifi certification version: v7.0
I (1916) wifi:config NVS flash: enabled
I (1926) wifi:config nano formating: disabled
I (1926) wifi:Init data frame dynamic rx buffer num: 32
I (1936) wifi:Init management frame dynamic rx buffer num: 32
I (1936) wifi:Init management short buffer num: 32
I (1946) wifi:Init static tx buffer num: 16
I (1946) wifi:Init tx cache buffer num: 32
I (1946) wifi:Init static rx buffer size: 1600
I (1956) wifi:Init static rx buffer num: 10
I (1956) wifi:Init dynamic rx buffer num: 32
[1B][0;32mI (1966) wifi_init: rx ba win: 6[1B][0m
[1B][0;32mI (1966) wifi_init: tcpip mbox: 32[1B][0m
[1B][0;32mI (1966) wifi_init: udp mbox: 6[1B][0m
[1B][0;32mI (1976) wifi_init: tcp mbox: 6[1B][0m
[1B][0;32mI (1976) wifi_init: tcp tx win: 5744[1B][0m
[1B][0;32mI (1986) wifi_init: tcp rx win: 5744[1B][0m
[1B][0;32mI (1986) wifi_init: tcp mss: 1440[1B][0m
[1B][0;32mI (1986) wifi_init: WiFi IRAM OP enabled[1B][0m
[1B][0;32mI (1996) wifi_init: WiFi RX IRAM OP enabled[1B][0m

NodeMCU ESP32 build unspecified powered by Lua 5.3.5 on IDF v4.4-dev-1849-g8e3e65a47b
cannot open init.lua:

Following:

> =node.heap()
2123699
> print("now it's working, with PSRAM enabled :)")
now it's working, with PSRAM enabled :)

That heap size guys ... even my worst code will fit easily.

Now for the serious questions:

As I'm not familiar yet with ESP32 series on nodemcu, asking if we can get into the approach to use ESP-IDF modules for WiFi and Mqtt handling (if not using yet) by making some kind of a wrapper or whatever, if it's not like that yet. Simply on ESP8266 there are some mysterious behavior with, in my view critical components for "internet connected" units, and not enough people to try to fix them.
Maybe we (I mean devs, with rights to post for the users like myself) should start using github discussions, as that would allow to keep issues more clean from the features development.

At the moment all from me, will try to run some usable code tonight. Thank you

edit

Also not sure about documentation (doc's branch) because ESP32S2 have many differences like lacking some modules (BT, CAN), different GPIO numbering, wider ADC (13 bit's), 1 core and so on. In my point of view it should have separate documentation.

@jmattsson thanks for the heads up regarding the UART & GDB Stub. There is a mistake in the code, it was supposed to check CONFIG_ESP_SYSTEM_GDBSTUB_RUNTIME instead. Will submit a fix ASAP.

Have tried to play a little bit more, WiFi is working. ADC is working. So tried mqtt module from an example in a esp32-dev. It not worked with an error:

dofile("mqtt.lua")
D (10505551) MQTT: MQTT client id clientid[0m
Lua error:  mqtt.lua:7: attempt to index a userdata value (field 'm')
stack traceback:
    mqtt.lua:7: in main chunk
    [C]: in function 'ROM.dofile'
    stdin:1: in main chunk
    [C]: in ?
    [C]: in ?

In the coming days I will try to test more peripherals but as a Marcel already mentioned this thread is getting long and also especially with my questions is getting out of scope. Same could be applied to the issues with this at the moment special branch which has nothing to do with the current main branches. So I will wait for you people to tell us how you will move forward with the IDF4 and where should we start posting issues.

Thank you

@igrr Ah, lovely, thanks Ivan! Dare I also mention that panic-to-gdb-stub is broken on the C3? ("undefined reference to esp_gdbstub_writemem"; looks like that's not implemented on riscv yet)

@KT819GM Thanks for reminding me. I needed to update the modules to comply with the new ordering restrictions in the rom tables. I've pushed a commit which should deal with the "attempt to index a userdata value" issue.

@marcelstoer I think this branch is just about ready. At $work we're already using parts of it in production (pre-5.1+5.3 introduction), and we're now testing with 5.3 and it's looking solid so far.

nodemcu / nodemcu-firmware

ESP32: Trying to build with the current IDF #3397

edit