Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 4923

SDK • Re: I2C random timeouts using i2c_write_timeout_us()

$
0
0
May I ask where you found this statement?
The I2C block does not support SMBus and PMBus protocols (for System Management and Power management).
RP2040 Datasheet 4.3.3. I2C Overview
What is puzzling though is that I do receive the correct bytes from slave and I believe according to the scope-pictures there is a NAK from slave followed by STOP by master at end of transfer but yet the function returns -2 (timeout).
When receiving, I think the master should do the ACK for every byte received, and NACK when stops.
If the master is reading from a slave (master-receiver), the slave transmits (slave-transmitter) a byte of data to the master, and the master then acknowledges the transaction with the ACK pulse. This transaction continues until the master terminates the transmission by not acknowledging (NACK) the transaction after the last byte is received, and then the master issues a STOP condition or addresses another slave after issuing a RESTART condition.
Try to compare a normal read with a timing out one, at higher zoom on scope.
Well, there's my answer to this issue I guess. Completely missed that during review and although it doesn't detail into what's not supported it's enough to rethink some decisions :/.
Modern I2C hardware and SMBus are mostly interoperable though so it would be interesting to hear the reason behind that statement.

Concerning the ACK and NACK-bits on scope pictures they do seem to follow I2C protocol which are also valid for SMBus. Master receiver will generate NACK when done clocking wanted bytes out from slave, which I can also see on my scope.
My mind earlier went to master writing but that's not the case in this scenario, my thinking went haywire but scope pictures are on point with I2C and SMBus protocol as far as I can tell.

Normal read vs timeout one is what got me puzzled to begin with. They are the same, so after a few days of testing and trying to figure out why it randomly timed out on what looks like a perfectly normal transfer I decided to try seeking help/suggestions here.
But... I believe there is no point in dragging this issue any further since the above statement from the datasheet was discovered.
I want to thank you guys for the ideas and eye-openers, very grateful for that.

Statistics: Posted by rhaa — Sun Jan 12, 2025 10:10 pm



Viewing all articles
Browse latest Browse all 4923

Trending Articles