TCA9548A: PIC16LF18857 I2C bus stuck busy when using TCA9548A I2C multiplexer (MSSP1 / MCC)

Part Number: TCA9548A

Hello everyone,

I am working on an I2C communication issue involving a PIC16LF18857, a TCA9548A I2C multiplexer, and downstream I2C sensors (e.g. SHT4x). The hardware works correctly when driven by an ESP32 (MicroPython), but I am having persistent problems on the PIC side.

Hardware setup

• MCU: PIC16LF18857-I/SS
  
  

• I2C peripheral: MSSP1 (I2C Host) generated with MCC
  
  

• Multiplexer: TCA9548A
  
  

• SDA/SCL on RC4 / RC3
  
  

• LATA4 → TCA9548A enable
  
  

• LATB3 (or similar) → TCA9548A reset
  
  

• External pull-ups present on SDA/SCL
  
  

Software environment

• MPLAB X + XC8
  
  

• MCC I2C_host driver (interrupt-based)
  
  

• Using I2C1_Write() / I2C1_IsBusy() / I2C1_ErrorGet()
  
  

Main problem

The program often gets stuck inside I2C1_IsBusy(), specifically because:

bool I2C1_IsBusy(void)

{

    return i2c1Status.busy || SSP1STATbits.S;

}

SSP1STATbits.S remains set, so the I2C bus is considered busy forever and the code blocks.

Sometimes, sending a “dummy” I2C write early in main() (e.g. a write to 0x70) clears the condition and allows execution to continue, but this feels like a workaround rather than a correct solution.

What I suspect went wrong

• I may not be initializing the MSSP/I2C peripheral in the correct order
  
  

• The bus may not be in a valid idle state (SDA/SCL high) when MSSP is enabled
  
  

• I previously mixed software (bit-banged) I2C and hardware (MSSP) I2C on the same pins, which may have left the bus or MSSP in an invalid state
  
  

• The TCA9548A might be powering up with channels disabled, and I may not be properly selecting a channel before accessing downstream devices
  
  

Questions

1. On PIC MSSP-based I2C, what is the correct startup sequence to guarantee the bus is idle before the first START condition?
   
   

2. Is it necessary or recommended to perform a bus recovery (clocking SCL manually) before enabling MSSP if the bus might be held low?
   
   

3. When using the TCA9548A, is it correct to:
   
   

   • First address 0x70
     
     

   • Write a single byte to select the channel
     
     

   • Then communicate normally with downstream devices on the same I2C bus?
     
     

4. If SSP1STATbits.S stays set, does that always indicate a missing STOP condition, or can it also be caused by external hardware holding the line?
   
   

5. Are there known pitfalls when using the MCC I2C_host driver with multiplexers like the TCA9548A?
   
   

Current status

• ESP32 + MicroPython works perfectly on the same hardware
  
  

• PIC code compiles and runs, but I2C frequently locks up
  
  

• LED/debug shows the code never exits the I2C busy state
  
  

Any advice, best practices, or pointers would be greatly appreciated.

Thank you very much for your time.