Thanks to visit codestin.com
Credit goes to github.com

Skip to content

esp32: Update ESP-IDF to v5.2.2, optimise size #15523

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Aug 14, 2024

Conversation

projectgus
Copy link
Contributor

@projectgus projectgus commented Jul 23, 2024

Summary

This PR updates the esp32 port's ESP-IDF version to v5.2.2 and changes the version build in CI from v5.0.4 to v5.2.2.

This is in anticipation of adding support for new SoCs ESP32-C6 (see #11869) and ESP32-C2 (see #15440) in the linked PRs.

Propose after merging this and changing the nightly version then we wait a couple of weeks and if no regressions are reported then remove support for older ESP-IDF, including some code cleanup to suit.

Code Size

The usual problem with updating ESP-IDF is an increase in code size. This PR applies some config changes to reduce resource usage, and also adds a utility script to quickly measure the static resource usage of multiple boards & ESP-IDF versions.

Current master branch resource usage:

BOARD BOARD_VARIANT IDF Version Binary Size Static IRAM Size Static DRAM Size
ESP32_GENERIC v5.0.4 1669037 128286 52892
v5.0.5 1682469 125822 53732
v5.1.2 1708393 129398 54276
v5.2 1707709 131150 55588
v5.2.2 1663573 121966 55236
ESP32_GENERIC D2WD v5.0.4 1425121 121270 52768
v5.0.5 1435673 118666 53608
v5.1.2 1456773 121306 54160
v5.2 1446181 121578 54776
v5.2.2 1399309 112318 54340
ESP32_GENERIC SPIRAM v5.0.4 1545837 130618 53308
v5.0.5 1557441 127802 54124
v5.1.2 1551761 128770 54540
v5.2 1543413 126870 55208
v5.2.2 1497321 117170 54788
ESP32_GENERIC_S3 v5.0.4 1564905 108674 49080
v5.0.5 1581793 104290 49344
v5.1.2 1595049 16383 138071
v5.2 1622129 16383 140159
v5.2.2 1632013 16383 143315
ESP32_GENERIC_S3 SPIRAM_OCT v5.0.4 1568157 110966 49980
v5.0.5 1585081 106582 50236
v5.1.2 1598289 16383 141267
v5.2 1625693 16383 143743
v5.2.2 1635609 16383 146923

Note that the ESP32-S3 pools IRAM and DRAM, so the last two columns need to be added together to be meaningful.

Resource usage after applying changes in this PR:

BOARD BOARD_VARIANT IDF Version Binary Size Static IRAM Size Static DRAM Size
ESP32_GENERIC v5.2.2 1627321 115310 55236
ESP32_GENERIC D2WD v5.2.2 1361777 108074 54332
ESP32_GENERIC SPIRAM v5.2.2 1459885 113046 54780
ESP32_GENERIC_S3 v5.2.2 1574649 16383 135299
ESP32_GENERIC_S3 SPIRAM_OCT v5.2.2 1578245 16383 138907

Summary:

  • For ESP32. the total binary size and the IRAM usage is now smaller on v5.2.2 with these changes compared to master branch with ESP-IDF v5.0.4.
  • For ESP32-S3 the total binary size got bigger moving from v5.0.4 to v5.2.2(!) but after applying these changes it's only a little bigger than ESP-IDF v5.0.4. Not sure why this is...
  • About 2344 less bytes of DRAM is available at runtime for ESP-IDF heap, compared to 5.0.4. As far as I can tell this is because of more "iram safe" error log strings that are linked to static DRAM. I can't see any easy way to tackle this, unfortunately.

Testing

  • Run unit tests on ESP32 and ESP32-S3
  • Add new unit test for SPI in linked PR
  • Run multi_bluetooth and multi_net tests on ESP32 and ESP32-S3
  • Test ESP32-C3 with built-in USB device

Other TODOs

Trade-offs and Alternatives

The main trade-off decision is keeping vs dropping support for older ESP-IDF, particularly as there is a small impact to available DRAM on v5.2.2. However supporting three different minor versions (5.0, 5.1, 5.2) is a lot of additional overhead for MicroPython, and the difference between 5.1 and 5.2 doesn't seem like it really justifies keeping 5.1 support around. Let me know if I'm wrong!

@projectgus projectgus force-pushed the update/esp-idf-522 branch 2 times, most recently from 9200a66 to d2a2abc Compare July 23, 2024 02:31
@projectgus
Copy link
Contributor Author

Rebased to pick up the changes in #15476, the numbers in the main post will be slightly wrong now.

@projectgus projectgus force-pushed the update/esp-idf-522 branch from d2a2abc to 03b13cf Compare July 23, 2024 03:19
Copy link

codecov bot commented Jul 23, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.43%. Comparing base (fb4ae1e) to head (0a11832).

Additional details and impacted files
@@           Coverage Diff           @@
##           master   #15523   +/-   ##
=======================================
  Coverage   98.43%   98.43%           
=======================================
  Files         163      163           
  Lines       21293    21293           
=======================================
  Hits        20959    20959           
  Misses        334      334           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link

github-actions bot commented Jul 23, 2024

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% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

@projectgus
Copy link
Contributor Author

I've started a discussion on Discord about more completely dropping support for older ESP-IDF in this PR, as there are a bunch of compatibility checks that we can simplify out:
https://discord.com/channels/574275045187125269/952412628926472273/1265452441932136550

Comments welcome.

@projectgus projectgus force-pushed the update/esp-idf-522 branch 2 times, most recently from 9ecdc15 to ec63829 Compare July 25, 2024 01:44
@projectgus
Copy link
Contributor Author

Have run unit tests, multi_bluetooth and multi_net (Wi-Fi) tests on ESP32 and ESP32-S3. Found one issue introduced by updating from v5.0.4 to v5.2.2 (mbedTLS-related commit in this PR), plus several other broken tests or bugs that were pre-existing (to be submitted in separate PRs).

With all these changes present I now see no test failures, apart from some quite infrequent stress test failures. 🎉

I wasn't able to test on ESP32-C3, both the boards I have are quite old (probably predating the C3's public release) and don't boot reliably on v5.2.2. I see some debug logs about missing eFuse calibration data, so I assume this is an issue with my boards and not MicroPython. Have ordered a newer C3 board, but if someone has a C3 at hand do they mind checking that it boots OK please?

@dpgeorge Based on @andrewleech's observation in Discord that some people ran into Wi-Fi issues with v5.2, I suggest we keep all versions supported in this PR but switch CI and nightly builds to v5.2.2. If no significant reports are received in a couple of weeks then I'll submit another PR to drop support for older versions and cleanup the code to suit. What do you think?

@projectgus projectgus marked this pull request as ready for review July 25, 2024 01:56
@dpgeorge
Copy link
Member

if someone has a C3 at hand do they mind checking that it boots OK please

I will check a C3.

I suggest we keep all versions supported in this PR but switch CI and nightly builds to v5.2.2. If no significant reports are received in a couple of weeks then I'll submit another PR to drop support for older versions and cleanup the code to suit. What do you think?

Sounds good!

@andrewleech
Copy link
Contributor

I've just compiled and flashed this to a new C3 board (recently received, been meaning to try it) using official IDF v5.2.2 docker

anl@STEP: ~/micropython $ esp-compile v5.2.2 ESP32_GENERIC_C3 /dev/ttyACM0
... snip ...
Wrote 3072 bytes at 0x00008000 in 0.0 seconds (599.7 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
Done
make: Leaving directory '/home/anl/micropython/ports/esp32'

anl@STEP: ~/micropython $ mpremote
Connected to MicroPython at /dev/ttyACM0
Use Ctrl-] or Ctrl-x to exit this shell

>>>
MPY: soft reboot
MicroPython v1.24.0-preview.137.gec63829b07.dirty on 2024-07-25; ESP32C3 module with ESP32C3
Type "help()" for more information.
>>>

@andrewleech
Copy link
Contributor

andrewleech commented Jul 25, 2024

I just ran multi tests between a C3 and S3 (FLASH_4M), both running 5.2.2 @ ec63829

Ran into a slight hiccup creating the keys ( #15545 ) but then:

anl@STEP: ~/micropython/tests $ ./run-multitests.py -ipyb:/dev/ttyACM0 -ipyb:/dev/ttyACM1 multi_net/*.py
multi_net/asyncio_tcp_client_rst.py on ttyACM0|ttyACM1: skip
multi_net/asyncio_tcp_close_write.py on ttyACM0|ttyACM1: pass
multi_net/asyncio_tcp_readall.py on ttyACM0|ttyACM1: pass
multi_net/asyncio_tcp_readexactly.py on ttyACM0|ttyACM1: pass
multi_net/asyncio_tcp_readinto.py on ttyACM0|ttyACM1: pass
multi_net/asyncio_tcp_server_client.py on ttyACM0|ttyACM1: pass
multi_net/asyncio_tls_server_client.py on ttyACM0|ttyACM1: skip
multi_net/asyncio_tls_server_client_cert_required_error.py on ttyACM0|ttyACM1: skip
multi_net/asyncio_tls_server_client_readline.py on ttyACM0|ttyACM1: skip
multi_net/asyncio_tls_server_client_verify_error.py on ttyACM0|ttyACM1: skip
multi_net/ssl_cert_ec.py on ttyACM0|ttyACM1: skip
multi_net/ssl_cert_rsa.py on ttyACM0|ttyACM1: skip
multi_net/sslcontext_check_hostname_error.py on ttyACM0|ttyACM1: skip
multi_net/sslcontext_getpeercert.py on ttyACM0|ttyACM1: skip
multi_net/sslcontext_server_client.py on ttyACM0|ttyACM1: skip
multi_net/sslcontext_server_client_ciphers.py on ttyACM0|ttyACM1: FAIL
### TEST ###
--- instance0 ---

Traceback (most recent call last):
  File "<stdin>", line 16, in <module>
OSError: [Errno 2] ENOENT

--- instance1 ---

### TRUTH ###
--- instance0 ---
b'client to server'
--- instance1 ---
b'server to client'
### DIFF ###
--- /tmp/tmp5czsrt2w    2024-07-25 16:09:40.301553122 +1000
+++ /tmp/tmpgz1a7lb_    2024-07-25 16:09:40.301553122 +1000
@@ -1,4 +1,8 @@
 --- instance0 ---
-b'client to server'
+
+Traceback (most recent call last):
+  File "<stdin>", line 16, in <module>
+OSError: [Errno 2] ENOENT
+
 --- instance1 ---
-b'server to client'
+
multi_net/sslcontext_server_client_files.py on ttyACM0|ttyACM1: skip
multi_net/sslcontext_verify_callback.py on ttyACM0|ttyACM1: skip
multi_net/sslcontext_verify_error.py on ttyACM0|ttyACM1: skip
multi_net/sslcontext_verify_time_error.py on ttyACM0|ttyACM1: skip
multi_net/tcp_accept_recv.py on ttyACM0|ttyACM1: pass
multi_net/tcp_client_rst.py on ttyACM0|ttyACM1: skip
multi_net/tcp_data.py on ttyACM0|ttyACM1: pass
multi_net/udp_data.py on ttyACM0|ttyACM1: pass
24 tests performed
8 tests passed
15 tests skipped: multi_net/asyncio_tcp_client_rst.py multi_net/asyncio_tls_server_client.py multi_net/asyncio_tls_server_client_cert_required_error.py multi_net/asyncio_tls_server_client_readline.py multi_net/asyncio_tls_server_client_verify_error.py multi_net/ssl_cert_ec.py multi_net/ssl_cert_rsa.py multi_net/sslcontext_check_hostname_error.py multi_net/sslcontext_getpeercert.py multi_net/sslcontext_server_client.py multi_net/sslcontext_server_client_files.py multi_net/sslcontext_verify_callback.py multi_net/sslcontext_verify_error.py multi_net/sslcontext_verify_time_error.py multi_net/tcp_client_rst.py
1 tests failed: multi_net/sslcontext_server_client_ciphers.py

Ah I see that failed test requires extra files created/copied onto the devices, my bad.

Ran into a slight hiccup creating the keys ( #15545 ) but then:

anl@STEP: ~/micropython/tests $ mpremote a0 cp *.der :
cp ec_cert.der :
cp ec_key.der :
cp rsa_cert.der :
cp rsa_key.der :
anl@STEP: ~/micropython/tests $ mpremote a1 cp *.der :
cp ec_cert.der :
cp ec_key.der :
cp rsa_cert.der :
cp rsa_key.der :

Urg, now many more tests fail

-b'server to client'
+
+Traceback (most recent call last):
+  File "<stdin>", line 114, in <module>
+  File "<stdin>", line 51, in instance1
+  File "ssl.py", line 1, in wrap_socket
+ValueError:
+The certificate validity starts in the future
+
+
multi_net/sslcontext_verify_callback.py on ttyACM0|ttyACM1: FAIL

I'm guessing you need to set the time on the devices somehow.... sorry I tried to help ;-D

@dpgeorge
Copy link
Member

I'm guessing you need to set the time on the devices somehow

Indeed! Try mpremote rtc --set.

@andrewleech
Copy link
Contributor

Indeed! Try mpremote rtc --set.

Oh that's easier than I was guessing, I forgot about that command thanks!
I've updated my readme pr with an appropriate note.

//
// Starting with mbedTLS 3.5, DER formatted keys must consume the entire keylen
// argument (no trailing bytes) or parsing fails. However, PEM formatted keys
// must be submitted with a terminating NUL byte included in the keylen...
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fix is actually being worked on separately in #14385.

@dpgeorge
Copy link
Member

I tested this PR with the two C3 boards that I have:

  • ESP32-C3-DevKitC-02
  • ESP32-C3-DevKitM-1

And IDF 5.2.2 with this PR does not work on either of them.

Looking at the DevKitC in particular, which has a ESP32-C3-WROOM-02 module. With this PR and IDF 5.2.2 the output on the /dev/ttyUSB0 serial when I press the RST button is:

$ mpremote
Connected to MicroPython at /dev/ttyUSB0
Use Ctrl-] or Ctrl-x to exit this shell
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:0x3fcd5820,len:0xf28
load:0x403cc710,len:0x89c
load:0x403ce710,len:0x2b14
entry 0x403cc710

When I use this PR but with IDF 5.0.5 I get:

$ mpremote
Connected to MicroPython at /dev/ttyUSB0
Use Ctrl-] or Ctrl-x to exit this shell
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:0x3fcd5820,len:0xe8c
load:0x403cc710,len:0x6ec
load:0x403ce710,len:0x2b24
entry 0x403cc710
MicroPython v1.24.0-preview.155.g768bdf99d on 2024-07-26; ESP32C3 module with ESP32C3
Type "help()" for more information.
>>> 

These are pretty old boards, but I think they should still work with IDF 5.2.2, considering they work with IDF 5.0.5. Comparing to @andrewleech 's C3 test above:

  • the DevKitC takes about twice as long to download firmware: Wrote 1602560 bytes at 0x00010000 in 56.3 seconds (227.6 kbit/s)...
  • it uses /dev/ttyUSB0 (not /dev/ttyACM0)

@andrewleech
Copy link
Contributor

andrewleech commented Jul 26, 2024

How interesting! With DevKitC is that via a UART bridge? Maybe it's the uart stdout that's changed?

My board is a cheap ESP32 C3 SuperMini which only exposes the built-in usb, this drops out on rst button and comes up as ACM.

$ make -C ports/esp32 BOARD=ESP32_GENERIC_C3 deploy PORT=/dev/ttyACM0

make: Entering directory '/home/anl/micropython/ports/esp32'
idf.py -D MICROPY_BOARD=ESP32_GENERIC_C3 -D 
<snip>
-- Building ESP-IDF components for target esp32c3
Processing 2 dependencies:
[2/2] idf (5.2.2)
-- Project sdkconfig file /home/anl/micropython/ports/esp32/build-ESP32_GENERIC_C3/sdkconfig
<snip>
[228/229] cd /home/anl/micropython/ports/esp32/build-ESP32_GENERIC_C3/esp-idf/esptool_py && /opt/esp...n_table/partition-table.bin /home/anl/micropython/ports/esp32/build-ESP32_GENERIC_C3/micropython.bin
micropython.bin binary size 0x19e1d0 bytes. Smallest app partition is 0x1f0000 bytes. 0x51e30 bytes (17%) free.
<snip>
esptool.py --chip esp32c3 -p /dev/ttyACM0 -b 460800 --before=default_reset --after=hard_reset --no-stub write_flash --flash_mode dio --flash_freq 80m --flash_size 4MB 0x0 bootloader/bootloader.bin 0x10000 micropython.bin 0x8000 partition_table/partition-table.bin
esptool.py v4.7.0
Serial port /dev/ttyACM0
Connecting...
Chip is ESP32-C3 (QFN32) (revision v0.4)
Features: WiFi, BLE, Embedded Flash 4MB (XMC)
Crystal is 40MHz
MAC: f0:f5:bd:fd:23:e4
Changing baud rate to 460800
Changed.
Enabling default SPI flash mode...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00004fff...
Flash will be erased from 0x00010000 to 0x001aefff...
Flash will be erased from 0x00008000 to 0x00008fff...
Erasing flash...
Took 0.19s to erase flash block
Writing at 0x00004000... (100 %)
Wrote 17408 bytes at 0x00000000 in 0.3 seconds (552.9 kbit/s)...
Hash of data verified.
Erasing flash...
Took 7.43s to erase flash block
Writing at 0x001ae000... (100 %)
Wrote 1696768 bytes at 0x00010000 in 24.8 seconds (547.9 kbit/s)...
Hash of data verified.
Erasing flash...
Took 0.03s to erase flash block
Writing at 0x00008800... (100 %)
Wrote 3072 bytes at 0x00008000 in 0.0 seconds (595.1 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
Done
make: Leaving directory '/home/anl/micropython/ports/esp32'

@dpgeorge
Copy link
Member

There must be a UART-USB bridge, because the USB stays alive over a reset.

The flashing output for this board is:

esptool.py --chip esp32c3 -p /dev/ttyUSB0 -b 460800 --before=default_reset --after=hard_reset --no-stub write_flash --flash_mode dio --flash_freq 80m --flash_size 4MB 0x0 bootloader/bootloader.bin 0x10000 micropython.bin 0x8000 partition_table/partition-table.bin
esptool.py v4.7.0
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-C3 (QFN32) (revision v0.3)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 7c:df:a1:af:4b:4c
Changing baud rate to 460800
Changed.
Enabling default SPI flash mode...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00004fff...
Flash will be erased from 0x00010000 to 0x001a3fff...
Flash will be erased from 0x00008000 to 0x00008fff...
...

@projectgus
Copy link
Contributor Author

projectgus commented Jul 26, 2024

These are pretty old boards, but I think they should still work with IDF 5.2.2, considering they work with IDF 5.0.5.

Agree. These are the same symptoms mine have, so I guess it's more widespread than just internal testing silicon. Will look into it more.

@dpgeorge
Copy link
Member

Agree. These are the same symptoms mine have

Mine don't give any errors about efuse.

Do your ESP32C3's work with this PR and IDF 5.0.5?

@dpgeorge
Copy link
Member

dpgeorge commented Aug 2, 2024

I've tested the latest version of this PR and it now works on my ESP32-C3-DevKitC-02 board.

Running all the tests, one fails: thread/stress_recurse.py. It looks like a stack overflow. This tests passes with this PR but using IDF 5.0.5. So I guess that IDF 5.2.2 somehow uses a little more stack for threads.

@dpgeorge
Copy link
Member

dpgeorge commented Aug 2, 2024

Running all the tests, one fails: thread/stress_recurse.py. It looks like a stack overflow. This tests passes with this PR but using IDF 5.0.5. So I guess that IDF 5.2.2 somehow uses a little more stack for threads

See #15583 for a proposed fix for that. @projectgus you may want to cherry-pick that commit into this PR to make testing easier.

@projectgus
Copy link
Contributor Author

projectgus commented Aug 7, 2024

Rebased.

My "ESP32-C3 SuperMini" board turned up, using the integrated Serial/JTAG. It seems to work correctly with the serial console config changes in this PR, also. Unit tests pass apart from:

Also:

  • Re-ran multi_bluetooth tests, they pass on S3 and C3[*]
  • Re-ran multi_net tests, also pass on S3 and C3.

[*] Except my new SuperMini board randomly resets sometimes mid-test for Bluetooth. Espressif DevKit-C3 does not do this. Pre-existing issue, fix in #15610 .

@dpgeorge This is ready apart from #15605 and also the mbedTLS certificate parsing fix. I don't think we should change the default IDF version to V5.2.2 without the mbedTLS fix, as cert parsing will fail. I still have a fix commit for that in this branch (86692a5), but I also made a suggestion to the author of the other fix PR here: #14385 (comment) . Do you have a preference for how to proceed on that one?

@projectgus
Copy link
Contributor Author

(Rebased again, cleaned up the metrics_esp32.py script and updated the numbers in the PR description.)

@dpgeorge
Copy link
Member

The mbedtls and stack-check PRs are now merged, so this is ready for a (final?) rebase and review.

@projectgus
Copy link
Contributor Author

projectgus commented Aug 14, 2024

@dpgeorge Thanks! Rebased, re-ran unit tests on ESP32, C3, and S3. I didn't rerun additional tests as I don't think there's a high risk of regressions in Wi-Fi or BT since the last test run.

mancausoft and others added 7 commits August 14, 2024 15:57
This new calibration routine exists for S3 in v5.1.1.  It works for all
platforms in 5.2.1.

Signed-off-by: Andrew Leech <[email protected]>
Disable unnecessary IRAM ISR functionality.

This work was funded through GitHub Sponsors.

Signed-off-by: Angus Gratton <[email protected]>
Replaces the deprecated ESP32 calibration API with the "line" method
instead.

This work was funded through GitHub Sponsors.

Signed-off-by: Angus Gratton <[email protected]>
Saves code size, MicroPython doesn't appear to rely on any of the missing
formatters (64-bit integers, c99-style named arguments).

Signed-off-by: Angus Gratton <[email protected]>
Keeping older versions, however if the update goes well then these may be
dropped in the future.

Signed-off-by: Angus Gratton <[email protected]>
The ESP-IDF default on C3 is primary UART0, secondary USB serial/jtag.
Previously MicroPython configured the primary as USB Serial/JTAG and
manually worked with the UART0 console. However UART0 console stopped
working this way in v5.2.2.

The big change is that CONFIG_ESP_CONSOLE_USB_SERIAL_JTAG is no longer set,
as primary console is UART0. However
CONFIG_ESP_CONSOLE_SECONDARY_USB_SERIAL_JTAG is set and IDF provides a
macro CONFIG_ESP_CONSOLE_USB_SERIAL_JTAG_ENABLED which is set if either
primary or secondary esp_console is USB serial/jtag. So need to use that
macro instead.

This work was funded through GitHub Sponsors.

Signed-off-by: Angus Gratton <[email protected]>
@dpgeorge dpgeorge force-pushed the update/esp-idf-522 branch from 973c505 to 0a11832 Compare August 14, 2024 06:27
@dpgeorge
Copy link
Member

I tested this on a ESP32-C3-DevKitC-02, running the main test suite, and then the network and bluetooth multitests. Everything passes (except multi_bluetooth/ble_irq_calls.py but that's currently broken on master).

@dpgeorge dpgeorge merged commit 0a11832 into micropython:master Aug 14, 2024
65 checks passed
@dpgeorge
Copy link
Member

Now merged!

Thanks @projectgus for all your effort testing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants