Raspberry Pi I2C Clock-Stretching Fehler

Zusammenfassung

Der Broadcomm BCM2835 Prozessor, der auf dem Raspberry Pi verwendet wird, enthält einen schwerwiegenden Fehler, der dazu führen kann, dass (a) die Kommunikation mit manchen I2C-Geräten unmöglich wird und (b) falsche Daten gelesen oder geschrieben werden.

I2C-Geräte, die "I2C clock-stretching" verwenden, sollten deshalb nicht direkt mit dem Raspberry Pi oder anderen Broadcomm BCM2835-basierenden Geräten verwendet werden.

Lösung:

keine

Umgehung des Problems:

siehe unten

Details

Laut I2C-Spezifikation dürfen I2C-Slaves während einer Kommunikation die Clock-Leitung auf "low" halten ("clock stretching") falls sie mehr Zeit für die Verarbeitung der Daten benötigen, um den I2C-Master zu bremsen. Nachdem ein I2C-Slave die Clock-Leitung wieder freigibt, muss der Master den Takt wieder an die Clock-Leitung anlegen.

Der Fehler im Raspberry Pi (bzw. eigentlich in dessen ARM-Prozessor Broadcomm BCM2835) besteht darin, dass der I2C-Takt lediglich "maskiert" wird, wenn ein I2C-Slave die Taktleitung auf "low" zieht, und der Raspberry Pi nicht sicherstellt, dass der nächste Takt die volle Länge besitzt. Dadurch können unzulässige "Spikes" auf der Taktleitung entstehen, die evtl. zu kurz sind, um vom I2C-Slave erkannt zu werden. Dies kann zu einer Verschiebung des Slaves gegenüber dem Master um 1 Taktzyklus führen, wodurch beide nicht mehr synchron laufen. Darüber hinaus scheint der Raspberry Pi die Datenleitung zu früh einzulesen, nämlich während der Slave die Taktleitung noch auf "low" hält. Dies bedeutet, dass selbst sehr sehr kurze clock-stretches dazu führen, dass der Raspberry Pi falsche Daten liest.

Der oben genannte Fehler kann dazu führen, dass Daten verfälscht (d.h. andere Daten empfangen als gesendet) werden, oder dass die Kommunikation mit bestimmten I2C-Slaves nicht mehr möglich ist. Der einzige Fall, in dem das "clock-stretching" beim Raspberry Pi korrekt funktioniert, ist, wenn der I2C-Slave den Takt direkt nach der I2C-Read-Acknowledge-Phase um mindestens 1/2 Takt-Periode verlängert.

I2C funktioniert mit dem Raspberry Pi also nur, falls

• die Slaves kein "clock-stretching" verwenden, oder
• die Slaves "clock-stretching" nur am Ende der I2C-Read-Acknowledge-Phase (nach dem Lesen des ACK/NACK) verwenden, und ihn dabei um mindestens 1/2 Takt-Periode verlängern.

I2C funktioniert nicht oder kann zu verfälschten Daten führen, falls

• ein Slave "clock-stretching" am Anfang einer I2C-Write-Acknowledge-Phase verwendet,
• ein Slave "clock-stretching" am Anfang einer I2C-Read-Acknowledge-Phase verwendet,
• ein Slave "clock-stretching" am Ende einer I2C-Read-Acknowledge-Phase verwendet, den Takt aber um weniger als 1/2 Takt-Periode verlängert (bereits sehr sehr kurze "stretches" führen zu verfälschten Daten), oder
• ein Slave "clock-stretching" außerhalb von Acknowledge-Phasen verwendet.

Umgehung des Problems:

• Nutzen Sie keine I2C-Geräte, die "clock-stretching" verwenden, mit dem Raspberry Pi. Glücklicherweise ist "clock-stretching" bei I2C-Sensoren wenig verbreitet.
• Falls Sie genau wissen, wie schnell Ihre I2C-Geräte sind, können Sie einen geringeren I2C-Takt wählen, so dass die I2C-Slaves schnell genug sind, um kein "clock-stretching" mehr zu benötigen.
• Verwenden Sie nur I2C-/SMBus-Geräte, die einen CRC unterstützen.
  (Unsere I2C-Platinen/Sensoren, die einen Mikrocontroller beinhalten, verwenden einen CRC.)
• Falls Sie das AdvaBoard RPi1 verwenden, können Sie dort einstellen, dass ein Mikrocontroller auf dem AdvaBoard zu kurze clock-stretches während der I2C-Read-Acknowledge-Phase verlängert, so dass damit I2C-Sensoren mit beliebig langen clock-stretches am Ende der I2C-Read-Acknowledge-Phase funktionieren.
• Falls Sie das AdvaBoard RPi1 verwenden, kann ein Mikrocontroller auf dem AdvaBoard RPi1 als "I2C-Proxy" dienen, und das Problem damit komplett umgehen. Auf diese Weise sollten dann alle I2C-Geräte funktionieren.
• Falls Sie selbst-programmierte Mikrocontroller als I2C-Slaves verwenden, sollten Sie der Kommunikation evtl. einen CRC hinzufügen. Alternativ könnten Sie eine schnelle Interrupt-Service-Routine für I2C-Writes verwenden, die den Takt nie verlängert, und eine Wartezeit von über 1/2 Clock-Periode zur I2C-Read-Acknowledge-Phase hinzufügen.
• Verwenden Sie einen SPI->I2C-, RS232->I2C- oder RS485->I2C-Adapter.
  (Wir werden demnächst derartige Adapter anbieten.)

Von der Raspberry Pi Foundation selbst oder von Broadcomm ist kaum Hilfe bzgl. dieses Problems zu erwarten. Das Problem ist ihnen mittlerweile (zumindest teilweise) bekannt; sie haben es aber leider weder dokumentiert, noch können sie eine Lösung bieten.

Messdaten

Hier sind einige Messdaten mit dem Raspberry Pi als I2C-Master und einem Mikrocontroller (SiLabs C8051F353) als I2C-Slave. Der Mikrocontroller war dabei schnell genug, um sogar die Clock-Spikes zu erkennen. Da der Raspberry Pi die Datenleitung jedoch zu früh liest, wurden die Daten dennoch verfälscht.

Es wurden verschiedene clock-stretching-Zeiten verwendet, und dabei SCL und SDA mit einem Oszilloskop vermessen. Zu beachten ist, dass nur das clock-stretching-Verhalten während der I2C-Acknowledge-Phase getestet wurde.

Links

Das Problem wurde teilweise im Raspberry Pi-Forum diskutiert, und es existiert ein (bislang unvollständiger) Hinweis im Wiki:

• I2C clock stretching im Raspberry Pi Forum
• I2C clock and data pins im Raspberry Pi Forum
• Errata-Eintrag im Raspberry Pi Wiki