⚠️ I2S Bus conflict for M5Stack Core2 v1.3 + ES8388 (M144) Audio Module + Bottom2 (A014-C)

YO3HJV

I am working on a project that involve ES8388 Audio Module and the Bottom2 as portability is a key feature.
At some point, I got stuck into an audio issue that appeared only when I stacked the Bottom 2 to the Core2+Audio Module.
After intensive debugging, I found the culprit by studying the pdf schematics for each module.

The investigation pointed to an I2S conflict on Pin 26 of the M5 BUS:

On one side, the Bottom2 module exposes on this Pin the DAT signal from the SPM1423 MEMS microphone, while on the other side, the Audio Module uses the same line for I2S_MAIN_DIN (ASDOUT from the ES8388 codec).

The problem is that the MEMS microphone is always active, continuously driving the data line. As a result, when the Audio Module is used together with Bottom2, the operation of the ES8388 is severely affected, leading to malfunction or unreliable behavior.

As a workaround, I physically removed the SPM1423 microphone from the Bottom2 PCB, which resolves the issue.
A more elegant solution would be a revision of the Bottom2 hardware design, such as:

adding a hardware switch to disconnect the microphone, or
routing the SPM1423 SELECT pin to a free GPIO (for example, GPIO36), allowing the microphone to be enabled/disabled via software. This will impact J2 Socket on Bottom2 but will allow the FW to switch the MEMS Microphone.
3..... ???? ANYONE WITH IDEEAS?

I will still investigate in search for a more elegant solution.

Cheers,
Adrian

YO3HJV

Root Cause Analysis

A detailed schematic review revealed the source of the problem.
All three components — Core2, Audio Module, and Bottom2 — are interconnected through the shared M5 BUS.
The Bottom2 module includes a SPM1423 MEMS microphone, which uses:

GPIO0 (BUS pin 24) for the clock signal (CLK)
GPIO34 (BUS pin 26) for the data signal (DAT, digital output)

The Audio Module, based on the ES8388 codec, uses:

GPIO0 (BUS pin 24) for I2S_MCLK
GPIO34 (BUS pin 26) for I2S_MAIN_DIN

This creates a fundamental hardware conflict on the I2S bus.

The Core Conflict

Two independent devices attempt to drive the same data line:

The ES8388 (M144 Audio Module) uses GPIO34 to send digitized audio data from its ADC (line-in or microphone) to the ESP32 via I2S.
The SPM1423 (Bottom2) uses the same GPIO34 to output PDM audio data from its internal MEMS microphone.

From the ESP32’s perspective:

GPIO34 is input-only

However, on the physical PCB traces, both devices are electrically connected to this same line and actively drive it.
This results in a classic and severe bus contention scenario:

Two outputs connected together

No arbitration
No isolation
No possibility for coexistence

Why This Cannot Be Solved in Software

At first glance, one might consider disabling the microphone via software. Unfortunately, this is not feasible due to both architectural and hardware constraints.
The Bottom2 doesn’t expose the SPM1423 MEMS dedicated enable/disable (chip select) pin.
The only way to silence it — effectively forcing its data output into a high-impedance (Hi-Z) state — is to stop its clock signal on GPIO0.
This leads directly to a deadlock:
If the M144 switch is set to position A:
GPIO0 is used as MCLK (mandatory master clock for ES8388 operation, typically 12.288 MHz)

If the switch is set to position B:
GPIO0 becomes I2S SCLK (bit clock)

Additionally:
The internal amplifier of the Core2 (NS4168) also uses GPIO0 for BCLK

In other words, GPIO0 is always actively used in any valid configuration.
Stopping the clock to disable the microphone would simultaneously break:

the ES8388 codec
or the Core2 internal audio path

Thus, there is no viable way to control the microphone via software without disrupting essential system functionality.

Design Oversight

The A/B switch on the M144 Audio Module was clearly designed to avoid clock conflicts (MCLK vs SCLK) with other peripherals.
However, the design completely overlooks the data line conflict on GPIO34.
This is particularly problematic because:

the Bottom2 module is an official M5Stack accessory
the SPM1423 microphone is always active by default
both modules are intended to be used within the same ecosystem

Despite this, their coexistence leads to a non-functional configuration when using the ES8388 input path.

Conclusion

This issue is not a matter of configuration, firmware, or library incompatibility. It is a fundamental hardware design conflict on the shared M5 BUS.
When Bottom2 is attached:

the SPM1423 microphone continuously drives the I2S data line
the ES8388 is unable to deliver valid audio data
the result is severe noise and corrupted signal

There is no reliable software workaround.
The only effective solutions are hardware-level:

physically removing or isolating the SPM1423 microphone
redesigning the Bottom2 PCB to include a switch or gating mechanism
routing the microphone control (e.g., SELECT or enable logic) to a dedicated GPIO

Until such changes are implemented, the ES8388 input functionality cannot be used in conjunction with the Bottom2 module in a stable and predictable way.
My solution was to remove the SPM1423 Microphone from the PCB.
Another solution is to cut the relevant pins from the Bottom2 BUS with the same effect - removing SPM1423 from the circuit.