TWI delay between address and read

[a.o.]

Hi, I am using TWI on a 52832 (sdk12.2) and am having problems with reading data. The slave chip that can take up to 60uS (8 bus clock cycles) between to set up data after receiving the address of a read request. Currently, this delay is about 27uS. What would be the best way to stretch this time? Thank you, Andrew

[endnode]

nRF52 is TWI master? If slave needs more time to process/prepare data then it should use clock stretching (hold it low), nRF52 TWI master peripheral block supports it and transport of next character should be delayed until slave releases SCL line. Also do both master and slave use same clock frequency?

[a.o.]

Thanks for the quick response.

Yes, the TWI is the master. Both the slave and the master (Nordic) claim to be clock stretching, but after an application engineer for the slave looked at the waveforms on a scope, he suspects that the timing is too short, causing intermittent incorrect reads of the slave's registers. What is interesting, is that the cases I have caught are the same value, independent of the register address. The suggestion was to add an artificial delay between ack and the data.

I added some bit flipping of an I/O pin to see where I had software control, and did not find a place where there was software access between the address/ack of the read, and the clock.

Thoughts?

[endnode]

It doesn't make much sense. If TWI (I2C) Slave issues ACK and doesn't stretch SCL then it should be ready to process next character. Do you have any trace from logical analyzer showing what is the timing on both lines, what is SCL frequency during character transport etc.?

[Levi]

Try adding an nrf_delay_ms() command in between the TWI write and read commands. I had a similar problem to this before and adding a few delays in and around these function calls fixed it.

[endnode]

I would say never play with nrf_delay_ms or nrf_delay_us (or any other busy-loop function calling NOP instructions) in real nRF5x FW outside some auxiliary debug code because that can kill timing which is absolute key for BLE stack and other fueatures...