Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.46%. Comparing base (8a56be6) to head (00839cd).

@@           Coverage Diff           @@
##           master   #19149   +/-   ##
=======================================
  Coverage   98.46%   98.46%           
=======================================
  Files         176      176           
  Lines       22811    22811           
=======================================
  Hits        22460    22460           
  Misses        351      351           

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

Wit esp_idf 5.5.4 it should be possible to drop the call to i2c_master_probe() in machine_i2c.c. As far as I followed the change notes, the required change to i2c_master_transmit_receive() was made already in v5.5.2. I'll test.

No pure joy. A zero length I2C write still causes an error message to be printed. But at least a NAK does not cause an error any more. So I can change the code to use i2c_master_probe() only for i2c.scan() (Zero length transactions). Then the additional probe for read/write of length > 0 are gone.

The code can now use i2c_master_execute_defined_operations() for 0-length writes, used by i2c.scan(). For other read/writes i2c_master_transmit() and i2c_master_receive() can be used. i2c_master_execute_defined_operations() behaves odd for receive with len=0. For now a receive with len=0 is silently discarded.

OK, thanks for testing with I2C. I'll see what I can do there.

I prepared a change already, but wanted to wait until this PR is merged.

I prepared a change already, but wanted to wait until this PR is merged.

Ah, very good, thank you! I'll leave it to you then.

I needed to set CONFIG_BT_NIMBLE_STATIC_TO_DYNAMIC=n because otherwise BLE crashes upon start up. Maybe in the future we can fix this and enable this option to save some RAM.

I've already looked into this a bit the last few weeks. I think it's possible and had it working, although I've currently disabled it in my tree again after I ran into other Bluetooth bugs and wanted to make sure it wasn't caused by this new feature. I'll see if I can polish that into a PR in the coming weeks.

Note: I've been running against v5.5.4 for a while, but I've been having a few stability problems with it. On my S3 boards I get random MMU entry fault errors which I don't get with older IDF versions (v5.5.2), as well as some issues with Bluetooth bonding. I'm actively investigating these; noting it here because that might be good to know.

Note: I've been running against v5.5.4 for a while, but I've been having a few stability problems with it

OK, thanks, good to know. In that case we might need to move to a lower release, eg v5.5.2. We can still support v5.5.4, but officially build with v5.5.2 (for example).

In that case I'll note to avoid v5.5.3 as well, as there Bluetooth is broken (see espressif/esp-idf#18323).

From v5.5.3 onwards, the following commits have been added:

commit 32895539f2f961673094de4c92812fe0571fb142
Author: wanckl <wanlei@espressif.com>
Date:   Mon Aug 18 22:12:43 2025 +0800

    fix(driver_spi): support un-aligned dma transaction and psram transaction

commit 3924afbf28ee0283a369984ec363d0662ab06dd5
Author: Wan Lei <wanlei@espressif.com>
Date:   Tue Jul 8 19:22:54 2025 +0800

    feat(spi_master): support dma transfer with psram directly

It will be nice to be on something newer than v5.5.2 in the future, in order to take advantage of this feature, as it is quite a significant improvement for large framebuffers, as they will no longer use a bounce buffer located in internal RAM for the DMA. This is effectively a large reduction in transient internal RAM usage for projects that try to use PSRAM framebuffers, probably due to insufficient internal RAM in the first place.

@DvdGiessen did you make any progress with stability of 5.5.4? If not then we will move only to v5.5.2 for now (but still support v5.5.4 for users wanting to build firmware with that IDF version).

Not yet. Unfortunately I don't have a small and fast reproduction, and there are more things competing for my time. But no need to block this MR; having the option to build against the newer IDF for users that don't touch or hit the bug I'm seeing is useful to merge.