Hi,
We are using the nrf-twim driver for i2c/twi communication in our project. We are using the Azotech IQS7222B chip for touch buttons in our product and have run in to issues with the TWI driver.
The IQS7222B has a RDY pin that is active low. It's only possible to communicate with the device when the RDY pin is low. So the RDY pin functions as an interrupt to notify the CPU that there is a new event to process. The problem is that when the IQS7222B sees a i2c STOP condition on the bus, the RDY pin goes high and the communication window is closed. When processing events, you need to read multiple registers to figure out what event occured, what the change was etc.
The issue is that as soon as you send a RX request using the TWIM driver from NRF, the driver sends a STOP condition. We want to be able to write multiple TX/RX transactions without sending a stop condition
I checkout out the nrf-twi driver as well which also doesn't support this. Found this comment in the i2c_nrfx_twi_transfer function:
/* - otherwise, just finish the transfer without
* generating the STOP condition, unless the current
* message is an RX request, for which such feature
* is not supported
*/
Checking the datasheet for the NRF52840 TWI peripheral:
"A typical repeated start sequence is one in which the TWI master writes one byte to the slave followed by reading M bytes from the slave. Any combination and number of transmit and receive sequences can be combined in this fashion. Only one shortcut to STOP can be enabled at any given time. The following figure shows a repeated start sequence where the TWI master writes one byte, followed by reading M bytes from the slave without performing a stop in-between."
As far as I interpret this, we should be able to send arbitrary sequences of RX/TX without any stops? I'm curious as to why the driver doesn't support this behaviour? I'm guessing there is a good reason but I can't figure it out from the driver code. Any suggestions would be appreciated.
We do have workarounds for this specific project, it's possible to reconfigure the chip to not close the window on STOP conditions. But I am curious as to why it is like this.
