machine.I2S is disabled in the official ESP32_GENERIC_C5 build - enabling it works on hardware (same as the C6 case)

[AndyBee12]

Summary

machine.I2S is not available in the official ESP32_GENERIC_C5 firmware, because it is explicitly disabled in the board configuration. Rebuilding with that single flag enabled produces a working I2S on real hardware, with no other source changes. This looks like the same situation that was reported for the ESP32-C6 in discussion #17151 and later fixed by PR #17644.

I would like to ask the maintainers whether the flag was disabled for a known reason, or whether it is simply a conservative default from the initial C5 bring-up that has not been revisited.

Environment

• Board: ESP32-C5-WROOM-1-N4 (chip reported by esptool as ESP32-C5 rev v1.2)
• Firmware: official ESP32_GENERIC_C5-20260406-v1.28.0.bin from micropython.org
• Host: Windows 11, esptool v5.3.1, flashed at 0x2000

The problem

With the official build:

>>> import machine
>>> hasattr(machine, 'I2S')
False

Importing it fails at module level:

AttributeError: 'module' object has no attribute 'I2S'

One detail worth recording, because it is misleading: the traceback points at machine.py, which suggests a stub file shadowing the built-in module. It is not - it is a frozen Python wrapper (sys.path contains .frozen, and machine appears twice in help('modules')). Querying the underlying C module directly gives the same answer, so nothing is being hidden:

>>> import umachine
>>> hasattr(umachine, 'I2S')
False

The cause

ports/esp32/boards/ESP32_GENERIC_C5/mpconfigboard.h, line 6:

#define MICROPY_PY_MACHINE_I2S              (0)

Two observations:

• It is the only peripheral explicitly disabled for this board; everything else follows the port default, which is (SOC_I2S_SUPPORTED).
• The line has been present since the very first commit that added the board ("esp32/boards: Add ESP32_GENERIC_C5 board definition.", 17 Nov 2025) and has never been modified since. The only other commit touching the file is the cosmetic MCU-name change of 15 May 2026. No commit message and no code comment explains the reason.

For reference, ports/esp32/machine_i2s.c uses the modern driver/i2s_std.h API (i2s_chan_handle_t, i2s_channel_init_std_mode, i2s_channel_write) and contains no chip-specific conditionals; it relies on SOC_I2S_NUM, which ESP-IDF defines for the C5. The ESP32-C5 does have an I2S controller (datasheet section 5.2.1.4) and ESP-IDF supports it.

What I tested

Built MicroPython v1.28.0 with ESP-IDF v5.5.1 for ESP32_GENERIC_C5, changing exactly one character:

#define MICROPY_PY_MACHINE_I2S              (1)

No other source modification was needed. Results:

1. The build completes cleanly - machine_i2s.c compiles for the C5 without errors or warnings that required attention.
2. On the flashed board, hasattr(machine, 'I2S') is True.
3. Functional test: streaming a 16-bit mono 22050 Hz WAV file in a continuous loop to an Analog Devices SSM2518 class-D amplifier (I2S BCLK/LRCLK/SDATA on IO7/IO9/IO8, amplifier configured over I2C). The loop restarts land exactly 4.00 s apart, matching the file duration, which shows the peripheral is clocking samples out at the configured rate rather than draining instantly.

Question

Was MICROPY_PY_MACHINE_I2S (0) set for a specific known problem on the C5, or is it a leftover from the initial bring-up? If the latter, could it be enabled in the official build, as was done for the ESP32-C6 in #17644?

I am happy to run any further tests on real C5 hardware, or to open a pull request if that is preferred.

[MLuc24]

The evidence points the way you suspected, and there is a detail in the port default that makes the case stronger.

ports/esp32/mpconfigport.h does not default this to off. It defers to the SoC capability macro:

#ifndef MICROPY_PY_MACHINE_I2S
#define MICROPY_PY_MACHINE_I2S              (SOC_I2S_SUPPORTED)

So the port already asks the chip whether it has I2S, and a board only needs an override to contradict that answer. Since you have I2S working on real C5 hardware with nothing but the flag flipped, SOC_I2S_SUPPORTED is evidently true for the C5 — which makes the (0) in the board file an override of a correct answer rather than a substitute for a missing one.

The C6 comparison supports it too: ESP32_GENERIC_C6 has no MICROPY_PY_MACHINE_I2S line at all, so it simply inherits the SoC default. That is consistent with the fix there having been to delete the override rather than to add anything.

Worth adding to your report, since you would otherwise fix half the problem: the C5 override is not only in the generic board. Searching the esp32 boards for a forced zero turns up three files:

ports/esp32/boards/ESP32_GENERIC_C2/mpconfigboard.h
ports/esp32/boards/ESP32_GENERIC_C5/mpconfigboard.h
ports/esp32/boards/SEEED_XIAO_ESP32C5/mpconfigboard.h

SEEED_XIAO_ESP32C5 carries the same line, so XIAO C5 users hit exactly what you hit, and a change touching only the generic board leaves them there. Both are C5, both presumably came from the same bring-up.

The C2 entry is a different case and I would leave it out of the request. If the C2 genuinely lacks I2S then SOC_I2S_SUPPORTED is already zero there and the line is merely redundant, not wrong — bundling it in invites a discussion you do not need for the change you actually want.

[AndyBee12]

Thanks - that is a better way to frame it, and it turns up something I had missed.

The port default. I had not looked at mpconfigport.h. Confirmed on current master:

#ifndef MICROPY_PY_MACHINE_I2S
#define MICROPY_PY_MACHINE_I2S              (SOC_I2S_SUPPORTED)
#endif

That does sharpen the argument. The port already derives the setting from the SoC capability macro, so a board file only needs an entry in order to contradict it. Since the C5 runs I2S with nothing changed but that flag, SOC_I2S_SUPPORTED is evidently true for this target, which makes the board-level (0) an override of a correct answer rather than compensation for a missing one.

The C6 precedent. Also confirmed: ESP32_GENERIC_C6/mpconfigboard.h contains no MICROPY_PY_MACHINE_I2S entry at all, so it inherits the SoC default. The fix there was to remove the override rather than to set it to (1). That looks like the right shape for the C5 as well - removing the line keeps the board following the SoC automatically, with no value to maintain by hand.

The second C5 board. Good catch, and you are right that I would otherwise have fixed half of it. SEEED_XIAO_ESP32C5/mpconfigboard.h carries the identical line:

#define MICROPY_PY_MACHINE_I2S              (0)

I do not have XIAO C5 hardware, so I cannot test that board myself. But it is the same silicon, and SOC_I2S_SUPPORTED is a property of the target rather than of the module, so the same reasoning should carry over.

Amended request. Remove the MICROPY_PY_MACHINE_I2S (0) override from both C5 board files:

• ports/esp32/boards/ESP32_GENERIC_C5/mpconfigboard.h
• ports/esp32/boards/SEEED_XIAO_ESP32C5/mpconfigboard.h

Leaving ESP32_GENERIC_C2 alone, for the reason you give: if the C2 has no I2S peripheral then SOC_I2S_SUPPORTED is already zero there and the line is redundant rather than wrong, which is a separate question from this one.

I am happy to open the pull request with that change, and I can retest on ESP32-C5-WROOM-1 hardware against whatever revision the maintainers prefer.

[Josverl]

I am happy to open the pull request with that change,

Please do,
And please test on the silicon you have access to with actual I2S devices, and add that info to the PR.
For other impacted boards , list then as to be tested/confirmed , and other that have those boards can help verify