ESP32: Trying to build with the current IDF

[pjsg]

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)?

[jmattsson]

Alright, our old VFS stuff has annoyed me enough that I'm doing something about it. Substantial overhaul in progress to switch things over to the RTOS safe VFS that's provided in the IDF, plus swapping file for standard io (hopefully). This should be the last breaking change for now I hope.

[jmattsson]

Okay, the VFS switchover is pushed. If someone is interested in creating a Lua shim for forwarding old file module functions over to io, I would not object. Personally I'm feeling pretty spent after all the IDF4 work over the last few months. Though it feels like it's been a much-overdue spring clean done at last. (Yes, it's spring down here)

[marcelstoer]

If someone is interested in creating a Lua shim for forwarding old file module functions over to io, I would not object.

I feel an old->new table with function names in the docs would be enough.

[pjsg]

I just updated to the new branch that eliminates the file functions, and esplorer (my ide) now doesn't work as it relies on the file.* methods to operate.

What do other people use as an IDE these days? Even, how do you download source onto an ESP32 board?

Philip

On Wed, Oct 20, 2021 at 10:38 AM Marcel Stör @.***> wrote:

If someone is interested in creating a Lua shim for forwarding old file module functions over to io, I would not object.

I feel an old->new table with function names in the docs would be enough.

— 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-947732371, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTPTLV5UMCTVHXV6YWTUH3H4HANCNFSM4XOAOVRQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[jmattsson]

Hmm, breaking Esplorer is indeed not ideal. I could certainly be convinced that we should perhaps then have a compatibility option in Kconfig that brings in whatever Esplorer needs then.

I do use Esplorer, but only for interactive testing. For putting code onto the system it's LFS all the way.

[pjsg]

Since you removed all the underlying stuff as well, I guess that we have to re-implement the required APIs in terms of the io ones....

On Wed, Oct 20, 2021 at 10:38 PM Johny Mattsson @.***> wrote:

Hmm, breaking Esplorer is indeed not ideal. I could certainly be convinced that we should perhaps then have a compatibility option in Kconfig that brings in whatever Esplorer needs then.

I do use Esplorer, but only for interactive testing. For putting code onto the system it's LFS all the way.

— 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-948201904, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTK35CM6UKA56NMFRFDUH54IHANCNFSM4XOAOVRQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[jmattsson]

Maintaining two separate file io implementations would not be a good idea, let alone the fact that the old one was very rusted onto our legacy VFS implementation. Do you know what file commands Esplorer sends? Or is perhaps the better option here to update the Esplorer code base to use the standard io functions?

[marcelstoer]

What do other people use as an IDE these days? Even, how do you download source onto an ESP32 board?

At https://nodemcu.readthedocs.io/en/latest/upload/ we also documented @AndiDittrich's NodeMCU-Tool and the nodemcu-uploader. The latter looks somewhat unmaintained.

Do you know what file commands Esplorer sends?

Warning! There be dragons! ESPlorer isn't exactly an engineering gem and it was even worse before someone added a Maven build and the GitHub CI workflow. If you scan https://github.com/4refr0nt/ESPlorer/blob/master/src/main/java/ESPlorer/ESPlorer.java for file. you'll find functions like open, close, read, fsinfo, remove, rename, format, flush, writeline, write, readline. As far as I understand ESPlorer only ever had "accidental" support for our ESP32 branch.

[jmattsson]

I just tried seeing if we could away with setting io as the metatable index for file, but sadly we weren't that lucky (f={} for k,v in pairs(file) do k[k]=v end file=setmetatable(f, { __index=io })).

Having had a look at that Esplorer source (thanks Marcel, and yikes, that's ... uh... creative... design), I see that it's still using non-object file/io even! It looks like we'll either have to reimplement the original non-object file i/o here on top of the standard Lua io, or teach Esplorer about standard Lua io. Neither strikes me as fun, but the latter is probably the cleaner of the two. Or if there's a middle path of having us keep io as __index on file and update Esplorer to use the subset that would be common between 8266 and 32 in that case, maybe? But if we're touching Esplorer it would probably be just as easy to test whether file.read or io.read is available and act accordingly.

[pjsg]

Yeah -- I was just looking at the Esplorer code as well, and I think that the easiest thing is to make it compatible. Also there are a couple of places where it uses tmr.wdclr() and those need to be changed to a if tmr.wdclr then tmr.wdclr() end

philip

On Thu, Oct 21, 2021 at 3:03 PM Johny Mattsson @.***> wrote:

I just tried seeing if we could away with setting io as the metatable index for file, but sadly we weren't that lucky (f={} for k,v in pairs(file) do k[k]=v end file=setmetatable(f, { __index=io })).

Having had a look at that Esplorer source (thanks Marcel, and yikes, that's ... uh... creative... design), I see that it's still using non-object file/io even! It looks like we'll either have to reimplement the original non-object file i/o here on top of the standard Lua io, or teach Esplorer about standard Lua io. Neither strikes me as fun, but the latter is probably the cleaner of the two. Or if there's a middle path of having us keep io as __index on file and update Esplorer to use the subset that would be common between 8266 and 32 in that case, maybe? But if we're touching Esplorer it would probably be just as easy to test whether file.read or io.read is available and act accordingly.

— 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-948916274, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTMGHQLTQSGC65FHHH3UIBPWNANCNFSM4XOAOVRQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[marcelstoer]

ESPlorer also relies on our node module but AFAICS the only "incompatibility" is calling the restart() function reset() in a tooltip.

Can we track "ESPlorer compatibility" in a separate issue?

But if we're touching Esplorer it would probably be just as easy to test whether file.read or io.read is available and act accordingly.

I agree.

[marcelstoer]

I think this branch is just about ready.

The docs mention "deprecated" in a couple of places: https://nodemcu.readthedocs.io/en/dev-esp32-idf4/search.html?q=deprecated. We use platform_print_deprecation_note for some of the deprecated code. Would this be a good opportunity to remove all that code?

[jmattsson]

Would this be a good opportunity to remove all that code?

There is certainly something to be said for getting all the breakage done in one go!

Slippery slope then has me mentioning our inconsistent function naming with somethings using underscores and others not...

[pjsg]

I put up a PR for ESPLorer -- I don't think that I caught all the issues. Did the wdclr method go somewhere in the esp32 branch? I think that we still need it.....

https://github.com/4refr0nt/ESPlorer/pull/91

On Thu, Oct 21, 2021 at 4:54 PM Johny Mattsson @.***> wrote:

Would this be a good opportunity to remove all that code?

There is certainly something to be said for getting all the breakage done in one go!

Slippery slope then has me mentioning our inconsistent function naming with somethings using underscores and others not...

— 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-948995031, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTMJ54C34XBGIW24D4DUIB4ZPANCNFSM4XOAOVRQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[jmattsson]

I don't think it's implemented. FreeRTOS does its own hung task detection, so on the esp32 you'd be more likely to want/need to use coroutines and/or node.task.post() to break things up.

Edit: and now you've got me wondering whether that's actually enough, considering how FreeRTOS does scheduling priority. Edit 2: Nope, that's not enough. So yeah, we should look at whether we can yield properly somewhere or otherwise keep the task watchdog happy.

Thanks for preparing and submitting that Esplorer PR!

[jmattsson]

Okay, I've provided a tmr.wdclr() function. I did not see a better way of implementing it, at least not while sticking to the public FreeRTOS API.

[pjsg]

While testing the explorer stuff, i did get a wdt expiry, so something can go wrong!

On Thu, Oct 21, 2021, 21:47 Johny Mattsson @.***> wrote:

Okay, I've provided a tmr.wdclr() function. I did not see a better way of implementing it, at least not while sticking to the public FreeRTOS API.

— 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-949192123, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTOYLC55GCMEJKZLYV3UIC7EPANCNFSM4XOAOVRQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[jmattsson]

Even with the just-added tmr.wdclr() function in use? That's... odd. I tortured it quite a bit on mine with both infinite loops and recurring node.task.post()s.

[pjsg]

No -- I think it was with the previous version....

On Fri, Oct 22, 2021 at 12:09 AM Johny Mattsson @.***> wrote:

Even with the just-added tmr.wdclr() function in use? That's... odd. I tortured it quite a bit on mine with both infinite loops and recurring node.task.post()s.

— 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-949269990, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTPHTJTETGBVEPEQY6DUIDPWBANCNFSM4XOAOVRQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[kxygk]

I just wanted to tack on here, in case someone else comes across this, that the current instructions on the dev-esp32 and dev-esp32-idf4 branch will not work for the C3 variant

https://nodemcu.readthedocs.io/en/dev-esp32/ https://nodemcu.readthedocs.io/en/dev-esp32-idf4/build/

If someone wants to try it, you need to make some minor changes to force the tools to build for this target (it defaults to the xtensa ESP).

Some of the dependencies are also a bit different on Ubuntu 22.04. For instance instead of python-pip it was python3-pip

1) you do the usual recursive clone as before

2) you need to call ./install.sh esp32c3

3) the make method won't work and you need to call the python script directly. First you need to specify the target /sdk/esp32-esp-idf/tools/idf.py set-target esp32c3

4) I think at this point you can configure what modules you want with make menuconfig - however do note that some of the Build Options have changed. I think the UART baud rate is no longer where it used to be

5) Then you can can build the IDF with ./sdk/esp32-esp-idf/tools/idf.py build

6) Then you can flash it with ./sdk/esp32-esp-idf/tools/idf.py -p /dev/ttyACM0 flash (modify the port to match your own)

I think I must have some minor error though. B/c while at this point I can connect with nodemcu-tool -p /dev/ttyACM0 terminal for instance, I can't actually upload code. If I try to upload code I get an error

> nodemcu-tool -p /dev/ttyACM0 upload lua_examples/webap_toggle_pin.lua 
[NodeMCU-Tool]~ Unable to establish connection 
[NodeMCU-Tool]~ Invalid node.chipid() Response: Lua error:      stdin:1: attempt to call field 'chipid' (a nil value)
stack traceback:
        stdin:1: in main chunk
        [C]: ?
        [C]: ? 

If anyone sees the problem, please do let me know :)

[pjsg]

Thank you for doing this investigation -- I just got a couple of C3 boards and it was on my list of things to try.

I'll try your steps and see if it works any better for me!

After getting my python environment correct (mostly doing pip install -r sdk/esp32-esp-idf/requirements.txt)

I get

CMake Error at sdk/esp32-esp-idf/tools/cmake/project.cmake:290 (__project):
  The CMAKE_C_COMPILER:

    riscv32-esp-elf-gcc

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.

[kxygk]

Oh I thought you guys had already been running on C3's :) I didn't realize i was going into terra icognita here

I didn't actually run pip install -r sdk/esp32-esp-idf/requirements.txt (where did you find this?). I think the build steps pulled in the python dependencies on their own. Though I could be wrong.. I did do some fiddling around before I got things working

I think when you run /.install.sh esp32c3 it should pull in all these toolchains. You can verify if the toolchain is present by going to ~/.espressif/ and searching for riscv32

On my system it ended up here: ~/.espressif/tools/riscv32-esp-elf/esp-2021r2-8.4.0/riscv32-esp-elf/bin/riscv32-esp-elf-gcc

(again, this was done automatically by the previous install step)

If it's present then it's some path issue I guess. I don't know how the env is set for this pip call you're making. This riscv32-esp-elf-gcc is not in my general system/user wide $PATH. Again guessing a bit, but when you do a idf.py build or the install.sh I'm guessing it supplies the correct path internally. But here you're calling it explicitly manually?

[jmattsson]

Things were working fine with my ESP32C3 back when I got it supported, but I haven't tinkered with it (or any ESP32) for some time now. The install.sh in the nodemcu-firmware directory should pull in everything needed, and the Makefile sets up the necessary paths.

[kxygk]

hmm, interesting - so you didn't hit this chipid issue..

What did you use for uploading/running code btw?

I'm not super clear if the chipid is something set in the firmware or as part of the code upload. I'm guessing the former. And you were using the idf at the submodule version? Or latest?

I'm going to comb through the build barf and try to find some clues EDIT: Everything looks kosher and I'm getting esp32c3 targets for everything

[jmattsson]

I just use make flash. Looking at the error message you posted earlier, it would seem that nodemcu-tool expects there to exist node.chipid() command in the Lua environment, which is only the case for the main ESP32 SoC (the later versions don't have a chip id).

[kxygk]

Oh, okay. I'll try a different tool instead of nodemcu-tool

Sorry, I'm kinda new to the whole nodemcu thing, but isn't makeflash just uploading the Lua based environment (firmware). And then you need to actually upload code you want to run separately?

Doesn't make flash only handle the first step? I'm probably misunderstanding something. I appreciate your insight and help

[jmattsson]

Ah, yes. Sorry, I'm not actually a user of the nodemcu-tool. I do use Esplorer at times for interactive use and occasional code upload. Mostly I guess I fall into the category of "advanced user" and put all my code into LFS (Lua Flash Store) which I configure to be embedded into the base firmware, so for me make flash writes both base firmware and application code. I don't know who maintains nodemcu-tool, but making them aware that node.chipid() is not always present would probably be a good thing.

[marcelstoer]

[NodeMCU-Tool]~ Invalid node.chipid()

Yep, this is from here https://github.com/AndiDittrich/NodeMCU-Tool/blob/master/lib/connector/device-info.js#L73-L101 @AndiDittrich actually expects a node.info but we don't have this for ESP32, see https://github.com/nodemcu/nodemcu-firmware/issues/2759.

[kxygk]

Thank you for all the suggestions. It was indeed an issue wtih nodemcu-tool. I switched to Esplorer and things are semi workeable. It's still a bit broken in that you can't actually upload the file through the "Save to ESP" button, but I was able to load the code directly with "Send to ESP"

Here is a snippet of the errors generated when you try to "Save to ESP"

file.remove("webap_toggle_pin.lua");
> file.open("webap_toggle_pin.lua","w+");
Lua error:  stdin:1: attempt to call field 'open' (a nil value)
stack traceback:
    stdin:1: in main chunk
    [C]: ?
    [C]: ?w = file.writeline;w([==[do]==]);
Lua error:  stdin:1: attempt to call global 'w' (a nil value)
stack traceback:
    stdin:1: in main chunk
    [C]: ?
    [C]: ?w([==[]==]);
Lua error:  stdin:1: attempt to call global 'w' (a nil value)
stack traceback:
    stdin:1: in main chunk
    [C]: ?
    [C]: ?w([==[wifi.mode(wifi.SOFTAP)]==]);

I'm guessing that this is an issue with Esplorer though and that the APIs for uploading code has just changed over time.

I tried to run the example webap_toggle_pin.lua. Since the Nodemcu API has changed substantially I made a handful of changes. Here is the code is someone needs a testable snippet. I successfully connected to the test network and got the webpage (haven't tested toggling an LED yet)

do

wifi.mode(wifi.SOFTAP)
wifi.ap.config({ ssid = "test", pwd = "12345678" })
wifi.start()

gpio.config({gpio={4} ,dir=gpio.OUT})
local srv = net.createServer(net.TCP)

-- from the docs: 
-- https://nodemcu.readthedocs.io/en/dev-esp32-idf4/modules/wifi/#parameters_2
-- Unless you change the value, the NodeMCU device will be given 
-- a local IP address of 192.168.4.1 
-- and assign your computer the next available IP address, 
-- such as 192.168.4.2.

srv:listen(80, function(conn)
  conn:on("receive", function(client, request)
    local buf = ""
    local _, _, method, path, vars = string.find(request, "([A-Z]+) (.+)?(.+) HTTP")  -- luacheck: no unused
    if (method == nil) then
      _, _, method, path = string.find(request, "([A-Z]+) (.+) HTTP")  -- luacheck: no unused
    end

    local _GET = {}
    if (vars ~= nil) then
      for k, v in string.gmatch(vars, "(%w+)=(%w+)&*") do
        _GET[k] = v
      end
    end
    buf = buf .. "<!DOCTYPE html><html><body><h1>Hello, this is NodeMCU.</h1>"
    .. "<form src=\"/\">Turn MYPIN <select name=\"pin\" onchange=\"form.submit()\">"
    local _on, _off = "", ""
    if (_GET.pin == "ON") then
      _on = " selected=true"
      gpio.write(4, 1)
    elseif (_GET.pin == "OFF") then
      _off = " selected=\"true\""
      gpio.write(4, 0)
    end
    buf = buf .. "<option" .. _on .. ">ON</option><option" .. _off .. ">OFF</option></select></form></body></html>"
    client:send(buf)
  end)
  conn:on("sent", function(c) c:close() end)
end)

end

On reset the chip (or maybe it's Esplorer?) provides a bunch of diagnostics which I'll just put here for reference

Soft restart by user command
node.restart()
I (2181559) wifi:flush txq
I (2181559) wifi:stop sw txq
I (2181559) wifi:lmac stop hw txq
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x403805c8
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x16cc
load:0x403ce000,len:0x930
load:0x403d0000,len:0x2d40
entry 0x403ce000
I (35) boot: ESP-IDF v4.4-beta1-284-gd83021a6e8-dirt 2nd stage bootloader
I (35) boot: compile time 12:56:42
I (35) boot: chip revision: 3
I (39) boot.esp32c3: SPI Speed      : 80MHz
I (44) boot.esp32c3: SPI Mode       : DIO
I (48) boot.esp32c3: SPI Flash Size : 4MB
I (53) boot: Enabling RNG early entropy source...
I (59) boot: Partition Table:
I (62) boot: ## Label            Usage          Type ST Offset   Length
I (69) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (77) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (84) boot:  2 factory          factory app      00 00 00010000 00180000
I (92) boot:  3 lfs              unknown          c2 01 00190000 00010000
I (99) boot:  4 storage          Unknown data     01 82 001a0000 00070000
I (107) boot: End of partition table
I (111) esp_image: segment 0: paddr=00010020 vaddr=3c0c0020 size=22638h (140856) map
I (142) esp_image: segment 1: paddr=00032660 vaddr=3fc8fc00 size=02bfch ( 11260) load
I (144) esp_image: segment 2: paddr=00035264 vaddr=40380000 size=0adb4h ( 44468) load
I (156) esp_image: segment 3: paddr=00040020 vaddr=42000020 size=bac48h (765000) map
I (275) esp_image: segment 4: paddr=000fac70 vaddr=4038adb4 size=04c88h ( 19592) load
I (279) esp_image: segment 5: paddr=000ff900 vaddr=50000000 size=00014h (    20) load
I (281) esp_image: segment 6: paddr=000ff91c vaddr=50000018 size=00010h (    16) load
I (295) boot: Loaded app from partition at offset 0x10000
I (296) boot: Disabling RNG early entropy source...
I (313) cpu_start: Pro cpu up.
I (321) cpu_start: Pro cpu start user code
I (321) cpu_start: cpu freq: 160000000
I (321) cpu_start: Application information:
I (324) cpu_start: Project name:     nodemcu
I (329) cpu_start: App version:      1.4.0-master_20151229-837-gceb6
I (336) cpu_start: Compile time:     May 19 2022 12:56:49
I (342) cpu_start: ELF file SHA256:  902cf6501c0e6de4...
I (348) cpu_start: ESP-IDF:          v4.4-beta1-284-gd83021a6e8-dirt
I (355) heap_init: Initializing. RAM available for dynamic allocation:
I (362) heap_init: At 3FC96EA0 len 00029160 (164 KiB): DRAM
I (368) heap_init: At 3FCC0000 len 0001F060 (124 KiB): STACK/DRAM
I (375) heap_init: At 50000028 len 00001FD8 (7 KiB): RTCRAM
I (382) spi_flash: detected chip: mxic
I (386) spi_flash: flash io: dio
I (390) sleep: Configure to isolate all GPIO pins in sleep state
I (397) sleep: Enable automatic switching of GPIO sleep configuration
I (404) cpu_start: Starting scheduler.
I (409) uart: queue free spaces: 3

LFS sig not correct: 0xe94080e6 vs expected 0xfafaa154
I (419) pp: pp rom version: 9387209
I (429) net80211: net80211 rom version: 9387209
I (439) wifi:wifi driver task: 3fca4be8, prio:23, stack:6656, core=0
I (439) system_api: Base MAC address is not set
I (439) system_api: read default base MAC address from EFUSE
I (439) wifi:wifi firmware version: 0d44bbe
I (449) wifi:wifi certification version: v7.0
I (449) wifi:config NVS flash: enabled
I (449) wifi:config nano formating: disabled
I (459) wifi:Init data frame dynamic rx buffer num: 32
I (459) wifi:Init management frame dynamic rx buffer num: 32
I (469) wifi:Init management short buffer num: 32
I (469) wifi:Init dynamic tx buffer num: 32
I (479) wifi:Init static tx FG buffer num: 2
I (479) wifi:Init static rx buffer size: 1600
I (489) wifi:Init static rx buffer num: 10
I (489) wifi:Init dynamic rx buffer num: 32
I (489) wifi_init: rx ba win: 6
I (499) wifi_init: tcpip mbox: 32
I (499) wifi_init: udp mbox: 6
I (499) wifi_init: tcp mbox: 6
I (509) wifi_init: tcp tx win: 5744
I (509) wifi_init: tcp rx win: 5744
I (519) wifi_init: tcp mss: 1440
I (519) wifi_init: WiFi IRAM OP enabled
I (529) wifi_init: WiFi RX IRAM OP enabled
LFS sig not correct: 0xe94080e6 vs expected 0xfafaa154

NodeMCU ESP32 build unspecified powered by Lua 5.1.4 [5.1-doublefp] on IDF v4.4-beta1-284-gd83021a6e8-dirt
cannot open init.lua: No such file or directory
> print(uart.setup(0, 115200, 8, 0, 1, 1 ))
E (1989) uart: uart_set_pin(637): tx_io_num error
115200
> 
Communication with MCU...
Got answer! Communication with MCU established.
AutoDetect firmware...

NodeMCU firmware detected.
=node.heap()
220104
>

random thoughts:

• There is a trailing on many lines [0m (might be an Esplorer issue)
• This looks like an error of some sort LFS sig not correct: 0xe94080e6 vs expected 0xfafaa154
• NodeMCU ESP32 build unspecified powered by Lua 5.1.4 [5.1-doublefp] on IDF v4.4-beta1-284-gd83021a6e8-dirt not sure why it's unspecified and what that means
• cannot open init.lua: No such file or directory I'm guessing it's some optional file that can be provided to run after boot
• [0;31mE (1989) uart: uart_set_pin(637): tx_io_num error not sure what this means :)

Thanks again for everyone's input. Everything is at least at a state where I can code the C3!

[KT819GM]

Did you used release rev of esplorer or did you build it? Philip have done a commit there to do basic esp32 support and if I remember correctly it should solve file upload problems.

[kxygk]

Oh yep, that was it. With the latest version things are better and I can upload files. I'll try to explore the LFS flashing method though b/c the rest of Esplorer is kinda finnicky. I'd rather use my normal text editor and upload with a command

[marcelstoer]

Here is the code is someone needs a testable snippet.

Oh, are you saying the Lua examples at /lua_examples don't actually work with the API in ESP32 branch(es)?

[kxygk]

the /lua_examples on the dev-esp32-idf4 branch don't seem to correspond to the API and docs on the same branch

Ex: https://github.com/nodemcu/nodemcu-firmware/blob/dev-esp32-idf4/lua_examples/webap_toggle_pin.lua

gpio.mode(1, gpio.OUTPUT)

If I'm not mistaken, under the new API this should be

gpio.config({gpio={4} ,dir=gpio.OUT})

(see: https://nodemcu.readthedocs.io/en/dev-esp32-idf4/modules/gpio/ )

but that wasn't a complaint! The API is already documented which is great - and updating the examples would probably be a last step before merging back into master. I just putting it up here in case someone is trying to also run on a C3 and needs a sanity test :)

[marcelstoer]

the /lua_examples on the dev-esp32-idf4 branch don't seem to correspond to the API and docs on the same branch

That's definitely any issue. I created #3523 to track this. Would you be willing to help us fix the examples?

[pjsg]

I just tried the C3 again, and it gets to:

I (481) wifi_init: rx ba win: 6
I (491) wifi_init: tcpip mbox: 32
I (491) wifi_init: udp mbox: 6
I (501) wifi_init: tcp mbox: 6
I (501) wifi_init: tcp tx win: 5744
I (501) wifi_init: tcp rx win: 5744
I (511) wifi_init: tcp mss: 1440
I (511) wifi_init: WiFi IRAM OP enabled
I (521) wifi_init: WiFi RX IRAM OP enabled

NodeMCU ESP32 build unspecified powered by Lua 5.3.5 [5.3-int32-singlefp] on IDF v4.4-beta1-284-gd83021a6e8-dirt
cannot open init.lua: No such file or directory

but I never get a prompt. It doesn't matter if I use esplorer or idf.py monitor. This is a pretty standard config with LUA5.3 (rather than 5.1).

Any ideas?

I'm using a board which just has the USB connected directly to the ESP32-C3.

[jmattsson]

That's odd. It works fine for me here.

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x16cc
load:0x403ce000,len:0x930
load:0x403d0000,len:0x2d40
entry 0x403ce000
 [0;32mI (30) boot: ESP-IDF v4.4-beta1-284-gd83021a6e8-dirt 2nd stage bootloader [0m
 [0;32mI (30) boot: compile time 11:04:22 [0m
 [0;32mI (30) boot: chip revision: 3 [0m
 [0;32mI (34) boot.esp32c3: SPI Speed      : 80MHz [0m
 [0;32mI (39) boot.esp32c3: SPI Mode       : DIO [0m
 [0;32mI (43) boot.esp32c3: SPI Flash Size : 4MB [0m
 [0;32mI (48) boot: Enabling RNG early entropy source... [0m
 [0;32mI (54) boot: Partition Table: [0m
 [0;32mI (57) boot: ## Label            Usage          Type ST Offset   Length [0m
 [0;32mI (65) boot:  0 nvs              WiFi data        01 02 00009000 00006000 [0m
 [0;32mI (72) boot:  1 phy_init         RF data          01 01 0000f000 00001000 [0m
 [0;32mI (79) boot:  2 factory          factory app      00 00 00010000 00180000 [0m
 [0;32mI (87) boot:  3 lfs              unknown          c2 01 00190000 00010000 [0m
 [0;32mI (94) boot:  4 storage          Unknown data     01 82 001a0000 00070000 [0m
 [0;32mI (102) boot: End of partition table [0m
 [0;32mI (106) esp_image: segment 0: paddr=00010020 vaddr=3c0c0020 size=22b58h (142168) map [0m
 [0;32mI (137) esp_image: segment 1: paddr=00032b80 vaddr=3fc8fc00 size=02c04h ( 11268) load [0m
 [0;32mI (139) esp_image: segment 2: paddr=0003578c vaddr=40380000 size=0a88ch ( 43148) load [0m
 [0;32mI (151) esp_image: segment 3: paddr=00040020 vaddr=42000020 size=beea0h (781984) map [0m
 [0;32mI (273) esp_image: segment 4: paddr=000feec8 vaddr=4038a88c size=05198h ( 20888) load [0m
 [0;32mI (277) esp_image: segment 5: paddr=00104068 vaddr=50000000 size=00014h (    20) load [0m
 [0;32mI (279) esp_image: segment 6: paddr=00104084 vaddr=50000018 size=00010h (    16) load [0m
 [0;32mI (292) boot: Loaded app from partition at offset 0x10000 [0m
 [0;32mI (294) boot: Disabling RNG early entropy source... [0m
  [0;32mI (310) cpu_start: Pro cpu up. [0m
 [0;32mI (319) cpu_start: Pro cpu start user code [0m
 [0;32mI (319) cpu_start: cpu freq: 160000000 [0m
 [0;32mI (319) cpu_start: Application information: [0m
 [0;32mI (322) cpu_start: Project name:     nodemcu [0m
 [0;32mI (327) cpu_start: App version:      tmr-libmain-binpatch150-821-gcb [0m
 [0;32mI (334) cpu_start: Compile time:     Jun 21 2022 11:07:39 [0m
 [0;32mI (340) cpu_start: ELF file SHA256:  e1ab6c53f4ddb87f... [0m
 [0;32mI (346) cpu_start: ESP-IDF:          v4.4-beta1-284-gd83021a6e8-dirt [0m
 [0;32mI (353) heap_init: Initializing. RAM available for dynamic allocation: [0m
 [0;32mI (360) heap_init: At 3FC96B70 len 00029490 (165 KiB): DRAM [0m
 [0;32mI (367) heap_init: At 3FCC0000 len 0001F060 (124 KiB): STACK/DRAM [0m
 [0;32mI (373) heap_init: At 50000028 len 00001FD8 (7 KiB): RTCRAM [0m
 [0;32mI (380) spi_flash: detected chip: generic [0m
 [0;32mI (384) spi_flash: flash io: dio [0m
 [0;32mI (389) sleep: Configure to isolate all GPIO pins in sleep state [0m
 [0;32mI (395) sleep: Enable automatic switching of GPIO sleep configuration [0m
 [0;32mI (402) cpu_start: Starting scheduler. [0m
 [0;32mI (407) uart: queue free spaces: 3 [0m
 [0;32mI (427) pp: pp rom version: 9387209 [0m
 [0;32mI (427) net80211: net80211 rom version: 9387209 [0m
I (437) wifi:wifi driver task: 3fca6cc0, prio:23, stack:6656, core=0
 [0;32mI (437) system_api: Base MAC address is not set [0m
 [0;32mI (437) system_api: read default base MAC address from EFUSE [0m
I (437) wifi:wifi firmware version: 0d44bbe
I (447) wifi:wifi certification version: v7.0
I (447) wifi:config NVS flash: enabled
I (447) wifi:config nano formating: disabled
I (457) wifi:Init data frame dynamic rx buffer num: 32
I (457) wifi:Init management frame dynamic rx buffer num: 32
I (467) wifi:Init management short buffer num: 32
I (467) wifi:Init dynamic tx buffer num: 32
I (477) wifi:Init static tx FG buffer num: 2
I (477) wifi:Init static rx buffer size: 1600
I (487) wifi:Init static rx buffer num: 10
I (487) wifi:Init dynamic rx buffer num: 32
 [0;32mI (487) wifi_init: rx ba win: 6 [0m
 [0;32mI (497) wifi_init: tcpip mbox: 32 [0m
 [0;32mI (497) wifi_init: udp mbox: 6 [0m
 [0;32mI (497) wifi_init: tcp mbox: 6 [0m
 [0;32mI (507) wifi_init: tcp tx win: 5744 [0m
 [0;32mI (507) wifi_init: tcp rx win: 5744 [0m
 [0;32mI (517) wifi_init: tcp mss: 1440 [0m
 [0;32mI (517) wifi_init: WiFi IRAM OP enabled [0m
 [0;32mI (527) wifi_init: WiFi RX IRAM OP enabled [0m
NodeMCU ESP32 build unspecified powered by Lua 5.3.5 [5.3-int32-singlefp] on IDF v4.4-beta1-284-gd83021a6e8-dirt
cannot open init.lua: No such file or directory
> =node.heap()
218948

[crodar33]

hi, I was need to add line ./${IDF_DIR}/tools/idf.py set-target esp32c3 in to 17 line of ./install.sh, I think it is need to be commited

[tomsci]

So happy to see S2 support in nodemcu :)

drop [extmod] 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.

For what it's worth I use extmod for a couple of really specific drivers that there's no point upstreaming, although I'm not sure if I'll ever upgrade those projects to the 4.x IDF.

Re adding the set-target command, I don't think putting that in install.sh is the right thing to do (unless you made a parameter to install.sh) - I've just been calling that command after install.sh and before my first make menuconfig call.

[jmattsson]

For what it's worth I use extmod for a couple of really specific drivers that there's no point upstreaming, although I'm not sure if I'll ever upgrade those projects to the 4.x IDF.

At $work we're actually using a small tweak to allow us to have IDF modules sit outside the nodemcu tree. I'll look at upstreaming that when I have a little bit of time.

[tomsci]

At $work we're actually using a small tweak to allow us to have IDF modules sit outside the nodemcu tree. I'll look at upstreaming that when I have a little bit of time.

@jmattsson any update on this? I bit the bullet and upgraded my extmod-dependent project (found some more fun new behaviours in IDF v4 along the way...), so not having to patch nodemcu source would be nice :)

[jmattsson]

Thanks for the reminder @tomsci ! I had indeed forgotten about this. I'm a wee bit under the pump getting firmware ready for EMC testing in the next couple of days, but I'll try to get a PR out this week. Please feel free to prod me again if I fail to do it!

[jmattsson]

@tomsci it took me longer than I'd hoped to get it done, but there's a PR over at #3563 now.

[marcelstoer]

As IDF 4(+) landed quite a while ago here we can probably close this?

[jmattsson]

Sounds reasonable; this one has turned into quite the catch-all anyway.