Alternating I2C transactions fail on STM32F4

[SumedhP]

Hello there,

I am working on a project using the STM32F427II where I am attempting to poll two AS5600 encoders via a TCA9548 multiplexer. I've encountered an issue where the result of the runTransaction alternates between true and false fairly consistently; essentially, every other I2C call seems to fail. Additionally, when increasing the read request rate, a significant portion of the requests fail intermittently. For instance, at a polling rate of 500Hz, there are alternating periods of approximately 100ms where no new data is read from the sensors.

To troubleshoot, I initially suspected that interrupts from UART might be causing the issue. However, after testing with only the encoders wired up, I observed similar behavior. My current workaround is to poll at 250Hz with two reads per iteration, assuming one call will fail.

This is my first time developing for this system and I am seeking further guidance. Is there a known issue with transactions failing when polling too fast, or is there something I might have misconfigured in my code?

Link to the repository. Relevant files are main.cpp and encoder class

[salkinium]

You're using resumable functions wrong by not polling the runTransaction for completion.

You need to wrap all calls to readRegister/writeRegister with RF_CALL_BLOCKING() to keep polling the transaction until it's finished.
You're currently kinda getting around it by using momd::delay_ms(100); after each write, but that doesn't actually check if the transaction finished.

For consistency you should also use RF_WAIT_WHILE() instead of the while loop in read-/writeRegister.

[salkinium]

btw, if you want to make this non-blocking, you can add a protothread and then use PT_CALL(readRegister(...)).

[salkinium]

I also saw that you use internal pullups with a 300kHz bus. The internal pull ups of the STM32 are somewhere in the range of 50-100kOhm, which is very weak, and limit the slew rate to slow bus speeds like maybe 10kHz. I would strongly recommend to use external pull ups (typically 1-10kOhm) to avoid any glitches on the bus.

[SumedhP]

Thank you for the reply! Passing along the comments about the pull-ups to my team. Question about making it a protothread, how does threading work with the multiplexer? If I make it a thread, isn't it possible for the thread interleavings to happen in a way where a multiplexer call reads from the wrong encoder? Please correct me if my understanding of protothreads is wrong.

[salkinium]

It should work fine, since a transaction cannot be started while another one is active. Unfortunately due to the nature of resumable (=async) function coloring, the modm::I2cMultiplexerChannel::start function calls the multiplexer in a blocking manner, which sucks a little. But fibers will improve that in future.