cancel
Showing results for 
Search instead for 
Did you mean: 

tca9548a not responding

TobiasChan
Associate

I have a STM32WB55 board where I have two I2C connections:
1. LSM6DSO IMU
2. TCA9548A with downstream I2C to hall sensors

The TCA9548A I2C multiplexer does not ACK when addressed. The firmware scans 0x70 (this should be correct already)–0x77 and gets no ACK. The LSM6DSO IMU on the same MCU works, so the MCU is fine; only the TCA9548A path fails. the A0, A1, A2 are all grounded, RESET pin is pulled up to VCC with the appropriate resistor, VCC and GND are wired correctly as well (~3.3V). TCA on PB8 (SCL) and PB9 (SDA) pins of the STM32WB55, each with 4.7k pull-up resistors to VCC. I even changed the PB8 PB9 pins to software I2C and back to hardwawre I2C, but no luck; I did even deeper diagnosis, and it is just that TCA9548A never ACKs at any address 0x70–0x77. 

The data is collected via BLE, the exact steps since I obtained the PCB are as follows:
1. Upgraded firmware on:
> FUS: stm32cubewb-v1-24-0\\\\STM32Cube_FW_WB_V1.24.0\\\\Projects\\\\STM32WB_Copro_Wireless_Binaries\\\\STM32WB5x\\\\stm32wb5x_FUS_fw.bin
> BLE: \\stm32cubewb-v1-24-0\\STM32Cube_FW_WB_V1.24.0\\Projects\\STM32WB_Copro_Wireless_Binaries\\STM32WB5x\\stm32wb5x_BLE_Stack_full_fw.bin in that order.
2. I verified by clicking on "read FUS info", FUS version: v2.2, STACK version: v1.24, STACK address: 0x80D0000, FUS operator: v3.1.0. And then I clicked "start wireless stack".
3. After all that, I went over to STM32CUBEIDE to flash my code, which lets assume has no problems. So the result was: BLE works, IMU works, TCA no ACK.

I have attached a screenshot of the PCB file and also the stm32programmer FUS status. I'm struggling to understand why TCA isn't responding, any help would be appreciated.

2 REPLIES 2
Peter BENSCH
ST Employee

Welcome @TobiasChan, to the community!

Unfortunately, you did not include an excerpt from the schematics.

  1. In your layout, I cannot find any pull-ups on pins 5 and 6 (which, by the way, are incorrectly labelled as IIC2). Are you sure they are present?
  2. Are you sure that the function of I2C1 has been selected for pins 5 and 6?
  3. What I2C clock have you set for I2C1?
  4. Have you looked at the signals on I2C1_SCL and I2C1_SDA?

Regards
/Peter

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hello Peter, thank you for your response. As for your questions:
Screenshot 2026-03-18 181739.pngScreenshot 2026-03-18 181751.png

1. Yes they are as shown above, where R35 and R36 are 4.7k ohm resistors and MCU_VDD net is the same as the VCC used for the I2C1 pull-ups (as shown on the bottom right corner). The naming should be fine as these are the only net wires for TCA <-> STM32WB55 I2C, I verified it.

2. Yes, PB8 is set to I2C1_SCL and PB9 to I2C1_SDA in CubeMX (.ioc file), and the MSP init configures them with alternate function 4 (GPIO_AF4_I2C1), open-drain with internal pull-ups.

3. I2C1 is clocked from PCLK1 at 32 MHz. The timing register is set to 0x00B07CB4, which gives Standard-mode ~100 kHz.

4. Not yet with a scope or logic analyzer. The firmware diagnostics show both lines idle HIGH after bus recovery, but I haven't captured the actual waveform during a transaction; I thought it's a hardware problem so i didn't go that far.