Maßnahmen gegen das Hängen bei SPI/I2C Kommunikation

Meine I2C-Funktionen geben als Rückgabewert true/false 
(erfolgreich/nicht erfolgreich) zurück und haben einen TimeOut. Der Rest 
ist einfach.

Wolfgang schrieb:
> fehlt ein Timeout

Wobei hier kann auch passieren dass sich der HW I2C Baustein sich 
verabschiedet hat. Danach könnte man versuchen den Baustein wenn es geht 
zu reseten. Aus und wieder einschalten könnte helfen. Manchmal aber auch 
nicht, da hilft dann nur der POR :(

Das Thema ist leider nicht so einfach. Wenn man anfängt mit HW 
Bausteinen zu arbeiten dann kann sein dass die sich aufhängen. Wenn man 
dann auf Bit Bang zurückgreift, dann wird man entweder den CPU aufhalten 
müssen damit man sehr schnell etwas schicken kann, oder es wird sehr 
langsam weil man eine State Maschine bauen muss.

Herbert schrieb:
> SysTick reicht, muss ja nicht hochauflösend sein

Mir ist es auch schon passiert, dass sich eine while Schleife 
aufgehangen hat.
Wie funktioniert das mit SysTick bzw. hat jemand für einen 
Programmierlaien einen konkreten Programmschnipsel, vorzugsweise für 
einen MSP430xxx ?

SPI/I2C sind grundlegend unterschiedlich, die kann man nicht in einen 
Topf werfen.

SPI kann nicht hängenbleiben, aber auch keine Übertragungsfehler 
feststellen. Da hilft nur saubere und kurze Verdrahtung, eventuell 
Treiber-ICs (differentiell).

Bei I2C kann sich der Master durch Störungen verklemmen, da hilft 
Timeout mit Disable.
Wurde bei einer Störung oder einem Reset gerade ein Slave als Sender 
adressiert, kann dieser SDA auf low ziehen (0-Bit senden). Da helfen 
dann bis zu 9 Takte auf SCL.
Oder der Slave disabled sich ebenfalls nach einem Timeout, falls er auch 
ein MC ist.

Teddy schrieb:
> weil vom Slave keine Antwort
> kommt?

Dieser Fall ist unmöglich, der Master liest immer was. Er kann nur 
vermuten, daß es Mumpitz ist, wenn er bei I2C 0xFF liest oder bei SPI 
das vorher gesendete Byte.

Sind alle Teilnehmer MCs, dann sollte man ein Protokoll mit CRC 
vorsehen. Ist die CRC falsch, dann liegt ein Fehler vor.

Ich verwende hausintern eine rabiat-robuste Methode, weil meine Systeme 
teilweise bis zu sechs Monate rennen müssen.

Einen FET, um die gesamten Slaves von der Stromversorgung zu trennen. 
Macht einer der HDC2010 Fiesipatentelen, schießt ihm der STM32L4 in den 
Kopf. Eine Sekunde ohne Energie, und gut.

W.S. schrieb:
> Mal abgesehen vom Clock-Stretching beim I2C

eben und wenn der Master nicht ewig warten will muss er sich selber eben 
aus dem Wartezustand befreien, er kann dann versuchen eine 
Abbruchsequenz zu senden und wenn das auch nicht hilft muß er eben einen 
Power On Reset auslösen und das geht nur am I2C slave durch 
Stromunterbrechung vom Slave.

W.S. schrieb:
> Mal abgesehen vom Clock-Stretching beim I2C, was man entweder im Treiber
> oder im zuständigen I2C-Peripherie-Core zeitlich begrenzt, gibt es die
> Sitation NICHT, daß vom Slave keine Antwort kommt.

Wenn ein sich irgendwie verhedderter Slave SCL und/oder SDA low zieht, 
steht der Bus. Da hilft dann nur noch der o.a. Kopfschuß...

Oliver

Man sollte die Hardware so hinbekommen, dass sie nie aussteigt. Ich 
musste noch nie einen SPI verkehr neu aufsetzen. I2C vermeide ich, da 
eher muehsam zu implementieren

Oliver S. schrieb:
> W.S. schrieb:
>> Mal abgesehen vom Clock-Stretching beim I2C, was man entweder im Treiber
>> oder im zuständigen I2C-Peripherie-Core zeitlich begrenzt, gibt es die
>> Sitation NICHT, daß vom Slave keine Antwort kommt.
>
> Wenn ein sich irgendwie verhedderter Slave SCL und/oder SDA low zieht,
> steht der Bus. Da hilft dann nur noch der o.a. Kopfschuß...
>
> Oliver

Ich sehe, noch jemand hat HDC2010 Erfahrung

Wir produzieren seit 1995 Geräte mit I2C-Bus, die 24/7 laufen.
Zuerst mit Philips 8051, da war nichtmal ein Timeout nötig.
Dann wurden die eingestellt und wir wechselten auf AVR. Die liefen ohne 
Timeout nicht mehr durch.
Aber die VCC abklemmen war noch nie notwendig.

Peter D. schrieb:
> Wurde bei einer Störung oder einem Reset gerade ein Slave als Sender
> adressiert, kann dieser SDA auf low ziehen (0-Bit senden). Da helfen
> dann bis zu 9 Takte auf SCL.

Diese 9 Takte sind eigentlich fast immer das Patentrezept, wenn der 
I2C-Bus klemmt.

Ich konnte das bei Tests nachvollziehen. Wird der µC mitten in einer 
I2C-Übertragung resettet/ausgeschaltet, dann kann sich der angesprochene 
I2C-Baustein (z.B. eine RTC) dabei aufhängen und SDA auf permanent auf 
low ziehen. Da hilft unter Umständen noch nichtmals ein Power-Off, wenn 
die RTC an einer Batterie hängt. Aber die 9 Takte helfen immer.

Vorgehen (Pseudo-C):

1

bool i2c_reset_bus ()

2

{

3

    uint_fast8_t i;

4

    bool         success = true;

5

6

    if (SDA_is_low ())    // SDA low?

7

    {                     // yes, reset i2c bus

8

        set_SCL_low ();

9

        delay_msec (1);

10

11

        for (idx = 0; idx < 9; idx++)

12

        {

13

            set_SCL_high ();

14

            delay_msec (1);

15

16

            if (SDA_is_high ())  // SDA now high?

17

            {                    // yes, we are ready

18

                break;

19

            }

20

21

            set_SCL_low ();

22

            delay_msec (1);

23

        }

24

25

        set_SCL_high ();

26

        delay_msec (1);

27

28

        if (SDA_is_low ())      // SDA still low

29

        {

30

            success = false;

31

            // log_message ("error: cannot reset I2C bus");

32

        }

33

    }

34

35

    return success;

36

}

Die Delays mit 1 Millisekunde sind nicht fix vorgeschrieben. Sie sollen 
nur verdeutlichen, dass man nach einer neuen Flanke etwas warten sollte.

Dies kann man eigentlich immer prophylaktisch in der i2c_init()-Funktion 
durchführen. Dann ist man auf der sicheren Seite.

EDIT: C-Pseudo-Code nochmals geändert und mit Kommentaren versehen.

Frank M. schrieb:
> Wird der µC mitten in einer
> I2C-Übertragung resettet/ausgeschaltet, dann kann sich der angesprochene
> I2C-Baustein (z.B. eine RTC) dabei aufhängen.

Das ist eine irreführende Aussage, denn er hängt sich gar nicht auf. Er 
bleibt einfach im Sende 0-Bit stehen, denn er kann ja nicht hellsehen, 
daß der Master resettet wurde.
Der Worst-Case ist, der Slave sendet 9 aufeinanderfolgende 0-Bits (ACK + 
8 Datenbits). Daher die bis zu 9 SCL-Takte, um SDA = 1 zu erhalten und 
das Startbit senden zu können.
Man muß nach jedem Takt prüfen, ob SDA = 1 ist, denn als Slave Receiver 
sendet der Slave nach 9 Takten wieder ein ACK, d.h. 0.

Die ganze Prozedur lang ist aber der Slave im regulären I2C-Modus und 
keinesfalls hängen geblieben oder abgestürzt.

Peter D. schrieb:
> Das ist eine irreführende Aussage, denn er hängt sich gar nicht auf.

Ja, natürlich, er hat sich nur "augenscheinlich" aufgehängt, weil er 
sich nicht erwartungsgemäß verhält, wenn ich das System einschalte.

Peter D. schrieb:
> Man muß nach jedem Takt prüfen, ob SDA = 1 ist,

Ist in obigem Pseudo-Code auch so drin, siehe "break".

Mike schrieb:
> https://www.nxp.com/docs/en/application-note/AN10216.pdf
> Seite 17 I2C Bus recovery.

"1 - Send 9 clock pulses on SCL line"

Darin fehlt jedoch das Abfragen nach jedem Takt. D.h. man kann in die 
Slave-Receiver Falle laufen und nach jeweils 9 Takten das nächste ACK 
sehen. Daß dazwischen der Bus frei ist (SDA = 1), merkt man so nicht.
Dieser Fall kann durchaus sehr wahrscheinlich sein, da der I2C-Interrupt 
im ACK-Slot wartet, bis das nächste Byte in den Sendepuffer geschrieben 
wird. Bleibt dann ein höher priorisierter Interrupt oder atomarer Block 
hängen und schlägt der Watchdog zu, dann ist das I2C in genau diesem 
Zustand.
Man verdächtig dann den I2C-Slave, obwohl der Fehler an einer völlig 
anderen Stelle passiert.

Trick 17 wäre natürlich:
- SDA abfragen
- SCL 10* takten // above 9 but not multiples of 9
- SDA abfragen

Damit wäre man asynchron zum ACK-Slot und der Leser kratzt sich verdutzt 
am Kopf.

jo mei schrieb:
> Peter D. schrieb:

> dito meine Firma. Wenn "solche Ereignisse" oder ähnliche notwendig
> wären, wären I2C Bausteine schon längst aus unseren Geräten ver-
> schwunden und intern hätte ein Aufschrei stattgefunden der seines-
> gleichen gesucht hätte. Doch lebt I2C bei uns weiterhin.
>

Hallo,
wenn ich kleine Flügelchen am Hintern hätte, wäre ich eine Yak40. Leider 
bin ich aber nur ein rassischer Halbaraber.

Die Sensorbausteine kommen allzu oft aus der Anwendung und du kannst sie 
nicht aussuchen. Wenn du es kannst, ich beneide dich. Ich kann es leider 
nicht...zumindest in dieser Applikation nicht.

lg
th

Christian J. schrieb:
> Lag
> vielleicht auch daran, dass sich der Hang-Up Zustand nicht künstlich
> erzeugen liess und die Routine nur aus dem Kopf geschrieben war in der
> Hoffnung, dass sie "wirkt".

Beim AVR ist das sehr einfach zu simulieren, da er genau in den 
kritischen ACK-Slots auf den Interrupt wartet. Man muß also nur eine 
Endlosschleife einfügen und auf den Watchdog warten.
Die Endlosschleife wird dann z.B. per UART-Befehl oder Taster 
getriggert.
Die UART gibt dann nach dem Watchdogreset aus, wie oft SCL getaktet 
werden mußte. Als Slave reicht ein einfacher PCF8574.

Aber es ist schon ein Armutszeugnis, daß über viele Jahrzehnte es noch 
kein MC-Hersteller geschafft hat, sowas in den I2C-Controller zu 
integrieren. Man könnte es automatisch vor jedem Startbefehl aufrufen.

Peter D. schrieb:
> Aber es ist schon ein Armutszeugnis, daß über viele Jahrzehnte es noch
> kein MC-Hersteller geschafft hat, sowas in den I2C-Controller zu
> integrieren.

Vielleicht ist das eine Charaktersache, weil man damit ja nicht das 
eigentliche Problem beseitigt ;) Man könnte nämlich auch am anderen Ende 
ansetzen:
Es ist eine Schande, dass es Port-Expander ohne Reset-Pin gibt und 
ausgerechnet solche besonders beliebt sind.
Es ist eine Schande, dass eine RTC das I2C-Interface im Batteriebetrieb 
nicht abschaltet.
Es ist eine Schande, dass es so wenig I2C-Peripherie mit integriertem 
Time-Out gibt. Ausgerechnet Maxim baut eine RTC mit I2C-Time-Out (und 
5ppm MEMS-Oszillator!), MAX31343. Aber die kennt natürlich wieder 
niemand :(

Bauform B. schrieb:
> Vielleicht ist das eine Charaktersache, weil man damit ja nicht das
> eigentliche Problem beseitigt ;)

Das Problem ist eigentlich nur, daß man I2C nicht verstanden hat.
Es liegt kein Fehler vor, sondern der Master wurde innerhalb eines 
Transfers resettet oder hat durch Leitungsstörungen die Arbitration 
verloren. Daher sollte auch der Master gefälligst den Slave wieder 
deadressieren, denn der Slave ist völlig unschuldig. Er verhält sich nur 
streng nach dem I2C-Standard. Daß der Standard kein Timeout definiert, 
mag nicht jedem gefallen, läßt sich aber nachträglich nicht mehr ändern.
Es hat dafür den Vorteil, daß es keine Maximalzeiten gibt, d.h. man kann 
I2C zu Fuß debuggen und keine Task muß auf I2C Rücksicht nehmen.

Bauform B. schrieb:
> Ausgerechnet Maxim baut eine RTC mit I2C-Time-Out

Dazu muß aber SCL >35ms auf low gehalten werden. Also muß man doch 
wieder das I2C disablen und mit den Pins spielen. Da mache ich lieber 9 
Takte, das geht bedeutend schneller.

Daß ein Master nach dem Reset einen adressierten Slave vorfinden kann 
und ihn deadressieren muß, ist ja nun kein großes Ding.

Aber es gibt leider auch buggy I2C-Controller, die als Multimaster so 
richtig Ärger machen. Da sträuben sich einem dann wirklich die Haare.

https://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html

https://community.st.com/s/question/0D50X00009XkgoY/stm32-i2c-multimaster-hardware-bug