Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TWI slave receiver releases SCL and returns to ready state prematurely #500

Open
jburks opened this issue Sep 26, 2022 · 1 comment
Open
Labels

Comments

@jburks
Copy link

jburks commented Sep 26, 2022

Commit 48bcef5 appears to have been an attempt to fix issue arduino/Arduino#1477. Contrary to what that issue says that problem was not exclusive to when two Arduinos are connected and the I2C slave Arduino was running at 8MHz; any slow device that stretched the I2C clock would hit the issue because the TWI master was not honoring an I2C clock stretch condition. That commit "fixed" the issue by having the slave receiver incorrectly release the bus before it was ready receive more data.

While the fix worked around a specific, exotic condition, it generally broke the case of Arduino ATmega328P as an I2C slave device on a fast-mode I2C bus (where responding to almost any request in a single clock cycle would be difficult) and did not solve the underlying problem in the issue which was that the TWI master did not honor clock stretching by slave devices (at the time; this may since have been fixed).

This is affecting a case where I'm using an Arduino ATmega328P as an SMC for a 6502 computer. The ATmega328P misses a portion of the I2C transaction because it does not stretch SCL and cannot process the last I2C byte and prepare a response before the next clock arrives. Using another 16MHz 8-bit AVR microcontroller (ATTINY861) does not exhibit this condition, even when the I2C handler's service time is substantially increased, because the Wire library implementation for that hardware does not release SCL prior to the service routine finishing.

@per1234 per1234 added the bug label Sep 26, 2022
@jburks
Copy link
Author

jburks commented Sep 26, 2022

A local change that reverts the commit mentioned did not fix this issue and caused other unexpected behaviors. I'm less confident that the specific commit is the root cause of the problem. The place where the clock stretching needed to happen may not have been at the stop/re-start state.

According to the ATmega328P datasheet (21.9.2 TWCR - TWI Control Register):

While the TWINT flag is set, the SCL low period is stretched.

The observed behavior on the logic analyzer does not show the clock being stretched, but I also do not see where TWINT is reset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants