Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% PICO
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

Codecov Report

Merging #11528 (1cb22e7) into master (41c9142) will not change coverage.
The diff coverage is n/a.

❗ Current head 1cb22e7 differs from pull request most recent head 6a9db52. Consider uploading reports for the commit 6a9db52 to get more accurate results

@@           Coverage Diff           @@
##           master   #11528   +/-   ##
=======================================
  Coverage   98.40%   98.40%           
=======================================
  Files         155      155           
  Lines       20543    20543           
=======================================
  Hits        20215    20215           
  Misses        328      328           

For the table above: I just tested this branch on both the ESP32-S2 and the ESP32-S3 and the ULP-FSM works correctly.

(To test, I used this sample code: #11761 (comment)).

I still want to test the same on the original ESP32 and will then let you know my result.

Now I tested this branch on the original ESP32 too and the ULP-FSM works correctly.

Thank you @wnienhaus ! I have updated the table.

I am using this on ESP32-S3 and can confirm SPIRAM works great there (gc.mem_free() shows me 4MB heap and it works), and UART REPL is fine. I have also tested WIFI STA and it works. It's a huge help for my project, so thank you!

@bwhitman did you delete a comment about LFS2 partitions not working? I just want to make sure everything is OK with that (it would be a show-stopper if it didn't work).

@bwhitman did you delete a comment about LFS2 partitions not working? I just want to make sure everything is OK with that (it would be a show-stopper if it didn't work).

I did. I thought it was due to the new MP or IDF, but it was because the new IDF gave me a new env where I re-installed littlefs-python, which got me a brand new version that made a LFS partition version 2.1, which was too new for MP / IDF 5.0.2. (It will return ENOENT if it's over 2.0. I eventually found it by turning on LFS debugging.) I've made an issue for that over there.. Apologies, I should have updated my comment instead of deleting it.

Apologies, I should have updated my comment instead of deleting it.

No worries. But, yes, definitely best to update your comment instead of deleting 😄

Tested: GPIO, I2C, SPI, RMT, NeoPixel, ADC, PWM across OG,S2,S3,C3. Also added REPL UART+USB on S2,S3, and Ethernet (IP101) on OG.

SD card code has been updated for IDF v5, and tested working on ESP32.

Tested PPP on OG/S3/C3, SDCard on S3.

@ThinkTransit if you programmed with a UF2 file then it's likely that the partition table is different to what's expected by the MicroPython firmware.

Can you run:

from esp32 import Partition
print(Partition.find(Partition.TYPE_DATA, label="vfs"))
print(Partition.find(Partition.TYPE_DATA, label="ffat", block_size=512))

?

If the first line prints None and the second line prints something else then you might be able to fix it by manually creating the filesystem:

os.VfsFat.mkfs(bdev)

Thanks @dpgeorge , creating the filesystem manually works.

>>> from esp32 import Partition
>>> print(Partition.find(Partition.TYPE_DATA, label="vfs"))
[]
>>> import os
>>> os.VfsFat.mkfs(bdev)
>>> 
MPY: soft reboot
MicroPython v1.20.0-239-g1cb22e7be on 2023-06-22; FeatherS2 with ESP32-S2
Type "help()" for more information.
>>> 

creating the filesystem manually works

In this case (programming with a UF2) it's assumed that the previous firmware has created the FAT filesystem.

To improve this situation we need to modify inisetup.py to detect if it should create a LFS or FAT filesystem, based on the Partition label.

creating the filesystem manually works

In this case (programming with a UF2) it's assumed that the previous firmware has created the FAT filesystem.

To improve this situation we need to modify inisetup.py to detect if it should create a LFS or FAT filesystem, based on the Partition label.

Ok makes sense thanks.

I just tested this board without the bootloader.

esptool.py --chip esp32s2 --port /dev/ttyACM0 erase_flash
esptool.py --chip esp32s2 --port /dev/ttyACM0 write_flash -z 0x1000 ports/esp32/build-UM_FEATHERS2/micropython.bin

again probably doing something wrong but the usb doesn't enumerate and a loadstore error is repeated on uart0. Could it be related?

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:0x3f000020,len:0x364a4
Panic at 4001126a
Fatal exception (3): LoadStoreError
epc1=0x4000ff4b, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3f000020, depc=0x00000000
ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4000f254
SPIWP:0xee
mode:DIO, clock div:1
load:0x3f000020,len:0x364a4
Panic at 4001126a
Fatal exception (3): LoadStoreError
epc1=0x4000ff4b, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3f000020, depc=0x00000000

I had this exact same error (LoadStoreError), when I used the wrong offset for the micropython.bin. I believe it should be 0x10000 (4 zeros) instead of 0x1000 (3 zeros). Now you would also have to write bootloader.bin to 0x1000 again, to restore a working bootloader, and likely partition-table.bin to 0x8000.

I've run our main project on this PR built with idf5.0.2 and everything worked correctly!

• Tested components : GPIO SPI SD Card I2C PWM WIFI STA Socket ESPNow BTree
• Tested on : ESP32

I've run our main project on this PR built with idf5.0.2 and everything worked correctly!

Very good, thanks for the additional testing!

I have also tested machine.I2S on ESP32, ESP32S2 and ESP32S3.

Merged!

Thanks. That was surely a lot of work. Time for a relaxed weekend.

@dpgeorge I've managed to rebase #8968 to include these changes and everything seems to be working but I've noticed that mDNS support and esp32_mbedtls_errors.c were left behind, is there any reason for this? So far I've managed to add mDNS support again and I will look into mbedtls_errors.c next, also now that the esp32 port is at mbedtls 3.3.0 maybe is time to revisit #8988 ? 👀

To improve this situation we need to modify inisetup.py to detect if it should create a LFS or FAT filesystem, based on the Partition label.

https://github.com/orgs/micropython/discussions/9961#discussioncomment-6227871

I've put my code up for this.

Would I submit a PR?

I've noticed that mDNS support and esp32_mbedtls_errors.c were left behind

I thought I left mDNS as is... but maybe I missed something there.

For the custom mbedtls errors, yes, I did not update that. The only downside there is that the error messages will be longer/take up more flash (and be different to other mbedtls ports...). For example what used to be:

OSError(-29184, 'MBEDTLS_ERR_SSL_INVALID_RECORD')

Is now (on esp32 with IDF 5):

OSError(-29184, 'SSL - An invalid SSL record was received')

I would like to eventually fix this (feel free to try!) but it's not a high priority at the moment.

also now that the esp32 port is at mbedtls 3.3.0 maybe is time to revisit #8988

Maybe... you already did update to v2.28.3 in 61b8e1b and it would be good to have that in the next release which is scheduled for the end of this month (!). Then we can update to v3.3.0 after the release.

I thought I left mDNS as is... but maybe I missed something there.

Yes, for some reason Espressif decided to move mDNS outside of the esp-idf repo, is now here esp-protocols, I had to clone it and copy the mdns component to esp-idf/components, add it to
esp32_common.cmake and include mdns.h in network_wlan.c and modsocket.c, after that it worked again as expected, I'll do a PR if necessary. 👍🏼

I would like to eventually fix this (feel free to try!) but it's not a high priority at the moment.

I agree

Then we can update to v3.3.0 after the release.

Yes, this is probably the best option 🤔

I'll do a PR if necessary

If you have time, that would be great.