Richard-Gemmell
commented
1 year ago Hi djholt,
This stall is generally known as a "stuck bus". It happens when the master and slave get out of sync. In your case the slave is trying to send a 0 and is waiting for the master to pulse the clock (SCL). Unfortunately, the master isn't expecting a bit for some reason. The master is probably trying to start a new I2C message but it thinks someone else is using the bus because SDA is low. Deadlock!
As a work around, you can "reset" the stuck bus on the Teensy by calling stop_listening() on the slave and then listen() again. You could probably set up a watchdog timer to track when you last received a message and do the reset if it times out. A more complex solution is to monitor the I2C bus directly. That's probably overkill in your case though.
There are lots of possible causes. To rule them out:
- make sure the master isn't resetting during an I2C message
- make sure the master and slave have a common ground
- keep wires short
- set the clock speed to 100 kHz if possible
It's possible that the master implementation does not support "clock stretching". If it's bit banging rather than using hardware support then it may well be a bit sensitive especially if it's handling other IO during an I2C message.
I've created the issue-30 with a couple of tweaks to the driver that might help. See this diff. Note that you MUST modify this file unless the bus speed is set to 100 kHz. It won't work as is at higher bus speeds.
The release version of the driver allows the slave to stretch the clock. I've disabled this by commenting out line 449. That might help if the master doesn't support clock stretching. This could well be the problem given that you are seeing the lockup when you write to GPIO.
I've added line 452 to make the slave wait a bit before changing the value of SDA. At the moment the slave is free to change SDA a few nanoseconds after the master drops SCL. This might confuse the master. If you're running at 400k or 1MHz you'll need to comment out line 452 and pick one of the lines underneath.
I've added line 457 to enable the slave glitch filter. This should make the slave less sensitive to noise. Like the change above, you'll need to pick the right line to suit your bus speed.
FWIW the last 2 changes may well be included in the release driver in the future.
I'd be curious to know:
- what bus speed you're running
- if the GPIO that triggers the fault is connected to the master
- whether the master supports clock stretching
- whether the master is bit banging or using I2C hardware support
I'd be most grateful if you could try to reproduce this fault with just the Teensy talking to itself. If you can, then please send me the source code. That'll enable me to find out exactly what's going on.
cheers, Richard
djholt
Hi Richard,
Thanks for your awesome work on this project. I'm trying to use a Teensy 4.1 as an I2C slave device connected to a proprietary master device, where the slave only reads data sent from the master. I've had good success with an Arduino Due, but I'm having some hanging issues with a Teensy 4.1. I'm hoping you can help point me in the right direction. Here's what I'm observing.
Occasionally, the I2C communication will stall. When stalled, SDA is kept low by the Teensy and no further bytes are read. I've finally determined that this will happen when I digitalWrite() to a completely unrelated GPIO pin (any pin, it seems) while I2C data is actively being received/read. This all happens in my loop(), and I've taken care to avoid any delay()-like operations, just in case that's an issue. My receiveEvent() function is included below. If I omit the digitalWrite() calls, the hanging stops entirely. Of note, this happens using the native Wire.h as well as i2c_driver_wire.h. The presence of external pullup resistors doesn't seem to make any difference. The stuck_bus and dev branches also produce the issue.
void receiveEvent(int howMany) { c = Wire1.read(); }
Any input would be much appreciated!