DF2301Q I2C asr.begin() hangs with TFT_eSPI tft = TFT_eSPI()
Steve.Parus 2026-08-05 12:14:25 23 Views1 Replies I am using a DF2301Q voice recognition module with I2C.
If I use it with a Waveshare Waveshare esp32-s3 1.91 amoled module, with code for it :
TFT_eSPI tft = TFT_eSPI();
the
while ( !( asr.begin() ) ) {
call hangs and never returns.
Simply commenting out the TFT_eSPI tft = TFT_eSPI(); results in the DF2301Q I2C being found.
Running an I2C scanner finds 0x64, 0x6B and 0x7E.
Changing the I2C/UART switch on the DF2301Q module to UART results in the 0x64 address not being present. So 0x64 is the DF2301Q I2C address and there is no other at that address.
I noticed the
DFRobot_DF2301Q.h has #define DF2301Q_I2C_ADDR uint8_t(0x64) //!< I2C address
but also in
class DFRobot_DF2301Q_I2C: public DFRobot_DF2301Q
says “…default to 0x50”
The TFT_eSPI constructor is grabbing a GPIO pin that your I2C bus needs. On the ESP32-S3 AMOLED, the default I2C pins are GPIO 8 (SDA) and GPIO 9 (SCL), and the TFT_eSPI User_Setup.h for that board likely maps one of the QSPI or control pins to the same numbers. When `tft = TFT_eSPI()` runs, it configures those pins for the display and the I2C bus stops responding — so `asr.begin()` hangs waiting for an ACK that never comes.
Check your TFT_eSPI User_Setup.h for any pin definition that overlaps with your I2C wiring. If the board's QSPI uses GPIO 8/9, move the DF2301Q to a different I2C pair (like GPIO 15/16 or 18/19) and call `Wire.begin(SDA_PIN, SCL_PIN)` before `asr.begin()`. The ESP32-S3 has two I2C controllers, so you can also run the display and DF2301Q on separate buses if the pinout allows.
On the address — the header defines `DF2301Q_I2C_ADDR` as 0x64, and the constructor defaults to that macro. The "default to 0x50" in the class comment maybe a doc error, ignore it. Your scanner already confirmed 0x64 is the right address.
Jason.Miao 