ESP32 Targets - Continued tested and fixes of IDF5

[SimonGAndrews]

@gfwilliams and @MaBecker

Good morning. Given the the IDF5 merge itself is completed ref closed issue espruino/Espruino#2731, But i believe we still have issues to close out, im starting this thread for general discussion to share further testing and identified issues , (given we will create specific githhub issues for those).

My status is im continuing to test the IDF5 builds of espruino across the classic (original ESP32), C3 and S3 targets , making sure the existing builds (classic and IDF4) are not broken in the process as Gordon has asked.

Im using Codex AI agent generated tests on the test harness boards i have made, with multiple peripheral devices incorporated as well and peer testing using an ESP32 C3 for BLE and EIFI testing. but lesson learnt earlier and for any issue ill share simple Espruino REPL code to demonstrate any issue.

I will continue to detail the issues but at the moment , im seeing issues in both the IDF5 and IDF4 builds across the targets. The issues are currently in the WIFI and BLE testing. The only one raised so far , from me is

• ESP32 - WIFI Ping not enabled in IDF5 and System memory low to sort it Espruino#2746 (currently testing fix)

Im seeing other IDF5 WIFI issues , whcih ill look at, and the peer testing is showing probable issues in the C3 BLE functionality in IDF4.

I note the ESP32 Github issues others have raised and appreciate @MaBecker adding the ESP32 tag.

More to follow. Any advice or direction please shout as always.

PS one general question for @gfwilliams , whcih ESP32 build are you using for your ongoing C3 work , IDF4 or IDF5 ? and I assume you still want both left working ??

[SimonGAndrews]

This one is on the list for investigation and formal raising with REPL tests.

Intermittent GATT Peripheral Failure
The failures included RISC-V load/store access faults and an ESP-IDF heap_tlsf.c heap-integrity assertion. Decoding the current image located the relevant frames at:

gatts_char_init(), targets/esp32/BLE/esp32_gatts_func.c:518;
gatts_create_structs(), the calloc() beginning at line 669;
gatts_set_services(), lines 693-694.

Initial Codex analysis - (Which I dont fully understand and is to be checked )

Current-master commit ed46a3a0b correctly changes active-service deletion to stop first and delete on ESP_GATTS_STOP_EVT. It removes the immediate BT_GATT: Active Service Found misuse, but it does not defer replacement service construction until all old applications have unregistered.

The runner initially performed a redundant NRF.sleep() cleanup after its hardware reboot. That was removed so the fresh reboot itself supplies the clean precondition. The fault remained and the decoded frames still pointed inside NRF.setServices(), so the final result is not attributed to that runner transition.

Source review also found that gatts_reset() declares esp_err_t r but does not assign the return from esp_ble_gatts_stop_service() before testing r. That should be corrected, although it does not by itself explain the decoded array-lifetime and heap-corruption failures.

[gfwilliams]

Ok, wow. Thanks for tracking this down - so this is instability specifically after espruino/Espruino@ed46a3a ?

Is that specifically when using NRF.setServices()? Or does the instability happen even when you're not adding new services?

If I'm honest the whole BLE service/characteristic situation seems a bit of a mess. The list of services seems to be being treated kind of like it's a list of connections sometimes. The more I try and use BLE for things the more I find is broken - and everything I can find online seems to say we should really be using NimBLE as a base, not Bluedroid - and we could save ~100k of RAM.

So quite a bit part of me wonders whether I should back that commit out if it's causing issues, and then actually try and rewrite the BLE stack from scratch to use NimBLE?

[gfwilliams]

which ESP32 build are you using for your ongoing C3 work , IDF4 or IDF5 ?

I'm actually using IDF5 now :)

When merging the IDF5 branch I wanted to check we weren't breaking existing builds (especially as I know some features had been commented out on IDF5), but I think now it's merged we should work on the assumption that at some point we will remove IDF4 and the legacy build. I still don't want to break them, but I don't think we should put any effort into fixing them. I feel like you've put so much effort into testing now that most people won't notice any IDF4 regressions over what was in the 2v29 release, so I think we're probably safe to focus testing and fixes solely on IDF5

[SimonGAndrews]

@gfwilliams RE The Intermittent GATT Peripheral Failure

Is that specifically when using NRF.setServices()? Or does the instability happen even when you're not adding new services?

So far this appears specific to NRF.setServices(). A Espruino JS minimal test repeatedly replaces the same custom service rather than accumulating new services. On the affected C3 IDF4 build, the first call returns and the fault occurs during subsequent asynchronous GATT processing, before the second call. We have not observed the same instability in BLE operation without custom service configuration, so I would not describe it as general BLE instability.

Ive raised the issue #2748 and submitted a Draft PR 2749

[SimonGAndrews]

Issue And PR 2752 are raised to explain and fix the wifi issue, Wifi.scan() returns an empty access-point list when starting station mode, whcih was identified in the IDF5 regression testing.

[SimonGAndrews]

Im aiming to get my outstanding test failures from this IDF5 validation testing investigated with issues raised where appropriate, ASAP. Were doing well, with just a few more to check out. At least one as been fixed , upon returning to it, with the increase heap change already, so ill identify them here one be by one here as I progress through them.

Just for a laugh, a picture of my workbench with four concurrent ES32 different targets attached and two on standby, Using Codex AI agent which as morphed into being able to decide what build to use and execute a flash on a given target for a given test or mid investigation to support diagnosis !!

Its a painful process with the multiple targets and IDF versions , but the use of Codex as made it manageable if not a little complex.

[SimonGAndrews]

Issue #2753 is raised for a wifi issue where On ESP32-family builds, Wifi.setIP() and Wifi.setAPIP() do not reliably agree with their callback result.

[SimonGAndrews]

And PR 2754 is raised to make the required changes to fix 2753

[SimonGAndrews]

[gfwilliams]

I didn't no (and that's from 7 years ago!) but it's not a huge surprise people are trying to cut down on the effort of development. I've done several badges now and I always find I end up spending so much time on them it's not worth it for me financially. Pimoroni even have their own 'Badge OS' with Micropython now as well: https://shop.pimoroni.com/collections/badgeware

Espruino's quite well set up for it since the app store for Bangle.js can be reused to loads apps (https://www.espruino.com/apps). The new epaper badge is really neat from that point of view (but the 4 color epaper takes so long to refresh that menus aren't really an option). I've currently got one on my desk showing solar power/battery state from Home Assistant - after the conference in question I'll stick the apps for it on to https://www.espruino.com/apps

[SimonGAndrews]

Having been away for a while im continuing to close our the ESP32 IDF5 testing.
A number of changes have been made over the last weeks to support the new IDF versions eg wifi ping .
So im running a full set of Codex AI agent assisted regression tests.

so these tests should pick up any issues with recent changes:

• modern IDF5 ping:
  0b4ff45fa;
• hostname corrections:
  6fb5cc927
  and
  1b48b2990;
• revised address parsing and formatting:
  4947f4ca3,
  736f24269
  and
  8637734c2;
• Wi-Fi resource cleanup:
  93378586b;
• additional scan handling and options:
  ba89989ef
  and
  d8405eb7b;
• allChannels connection support:
  8a582a34b;
• WPA3 changes:
  a195b28fb
  and
  7a83c3d59;
• IPv6 experimentation followed by IPv6 being disabled again for reliability:
  19a0c6c41,
  1b48b2990,
  981e4b682
  and
  bad3fc7a5;
• later classic ESP32 build corrections:
  47be6fe40,
  c9a6e0c6b
  and
  e73051ad4;
• expanded ESP32.getState() information:
  b08a2ea1f,
  f4e59d424
  and
  2a1f9c584.

[SimonGAndrews]

Initial tests on the classic ESP32 showed the recent TX Buffer change has cause an issue with an invalid UART configuration. See new PR to fix this espruino/Espruino#2768