Mic and Speaker at same time ???????? hardware lemon ? #10
Description
- Hardware Architecture Conflict (The "Shared Bus" Trap)
The primary issue is the I2S Bus Pin Sharing. The watch attempts to run a Microphone (ES7210) and a Speaker/Codec (ES8311) on the same I2S clock lines (BCLK/LRCK).
The Conflict: While I2S technically allows for shared clocks, the ES7210 and ES8311 chips on this board have different timing requirements for initialization.
The Result: Initializing the Speaker (TX mode) often "locks" the clock in a way that prevents the Microphone (RX mode) from starting. This is why we saw ESP_ERR_INVALID_STATE (Error 258) constantly.
- Driver Layer Incompatibility (Legacy vs. Modern I2S)
The current Waveshare example code relies on the Legacy I2S Driver, which is deprecated in ESP-IDF v5.0+.
The Conflict: The legacy driver does not handle "Simultaneous Duplex" well on the ESP32-S3 when multiple tasks (like an LVGL Spectrum and a Recorder Task) try to access the bus.
The Result: The "Swiss Cheese" code effect. When one task tries to "recover" the I2S state, it forces an uninstallation of the driver while the other task is still reading, leading to Guru Meditation Error (LoadStoreError) crashes.
- ES7210 "Deep Sleep" & I2C Handshake Failures
Our register dumps revealed that the ES7210 (Microphone ADC) frequently stayed in a reset or low-power state (returning 0x00 across registers) even after an I2C "Success" message.
The Problem: The ES7210 requires a very specific MCLK (Master Clock) presence before it will accept configuration commands.
The Failure: Because the ES8311 (Speaker) was often holding the MCLK line, the ES7210 refused to wake up. This resulted in "0.0% Non-Zero Samples"—the ESP32 was listening, but the Mic chip was essentially "muted" at the hardware level.
- Direct Hardware Failure (The Lemon Factor)
Despite achieving a stable, crash-free code state and verifying every I2C register was correctly set:
The Symptom: The I2S data line (GPIO 42) returned only binary zeros.
The Conclusion: Either a cold solder joint on the MEMS microphone or a defective ADC gate within the ES7210. On a device advertised for "AI Voice," the high failure rate of the audio path suggests a QA issue in the first-generation PCB.
Waveshare Watch V1 has a Hardware I2S Bus Contention issue that makes full-duplex audio (recording + visualizer) impossible without massive logic-blocks that eventually cause memory leaks.
Shared Clock Contention: The board tries to run two different audio chips (ES7210 and ES8311) on a shared I2S bus, but the chips have conflicting initialization timings.
I2C Ghosting: Even when I2C reports a "Success" connection to the Mic chip, the register dumps show the chip is stuck in a hardware reset loop because it isn't receiving the Master Clock (MCLK) correctly from the ESP32-S3.
Zero-Sample Deadlock: Even with stable, crash-free code, the data line (GPIO 42) remains physically silent (solid zeros), suggesting a hardware disconnect between the Mic and the ADC.