TWI delay between address and read

RE: TWI delay between address and read

Sridhar Jonnavittula — Mon, 07 Sep 2020 11:28:33 GMT

Hi,

I integrated my project in eddystone and TWI read work with out delay but if I integrate into HTS delay of 1sec after TWI init.

Can you please tell this issue?

RE: TWI delay between address and read

a.o. — Fri, 20 Oct 2017 20:58:41 GMT

I don't have a logic analyzer trace handy. I ended up retrying the read, and later found reference to the sensor chip not really supporting 100KHz clock. Can I go slower on this one port?

RE: TWI delay between address and read

a.o. — Mon, 10 Apr 2017 20:56:24 GMT

I added some bit flipping to see if I had software control in the appropriate part of the transfer, but I couldn't find a spot where the delay could be inserted.

RE: TWI delay between address and read

Levi — Mon, 10 Apr 2017 15:42:29 GMT

Interesting. Perhaps I will have to rework my own TWI code once I integrate it to a BLE project...

RE: TWI delay between address and read

endnode — Mon, 10 Apr 2017 13:34:11 GMT

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...

RE: TWI delay between address and read

Levi — Mon, 10 Apr 2017 13:28:24 GMT

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.

RE: TWI delay between address and read

endnode — Sun, 09 Apr 2017 17:35:19 GMT

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.?

RE: TWI delay between address and read

a.o. — Sun, 09 Apr 2017 16:13:09 GMT

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?

RE: TWI delay between address and read

endnode — Sun, 09 Apr 2017 13:15:06 GMT

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?