Unterbrechnung beim TWI sorgt für stetigen Reset (SHT41 an Atmega88)

OP #8107691

Ich möchte einen SHT41 über eine Steckverbindung an einem Atmega88 betreiben. Auf dem Steckbrett funktioniert der Aufbau schon wie gewünscht.

Testweise habe ich mal versucht eine Leitung zum SHT41 zu unterbrechen (während der Laufzeit). Der Atmega befindet sich dann in einem endlosen Reset. Dabei ist unerheblich welche der vier Leitungen ich unterbreche.

Ist das normal und kann man das verhindern?

Wie gesagt, im späteren Aufbau ist die Verbindung über eine Steckverbindung realisiert. Bei einer Unterbrechnung würde ich gerne im Controller darauf reagieren können. Die Initialisierung scheint noch zu funktionieren, aber beim ersten Zugriff resettet der Controller.

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Langsamer Modus Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Melden Danke

Clemens schrieb:

Der Atmega befindet sich dann in einem endlosen Reset.

Clemens schrieb:

Die Initialisierung scheint noch zu funktionieren, aber beim ersten Zugriff resettet der Controller.

Klingt nach Softwarefehler. Zeig mal den Code. Den Schaltplan brauchen wir auch (wurde schon angefragt).

Pull-up Widerstände sind an SCL und SDA vorhanden, nehme ich mal an. Ansonsten: rüste sie nach, denn I2C muss im Ruhezustand High Pegel haben.

: Bearbeitet durch User
Antwort Zitieren Bearbeiten Löschen Melden Danke

Oliver S. schrieb:

AVR und TWI ist einfach … unschön.

Wieso das denn? Läuft völlig problemlos und nebenbei im IRQ:

  • Eine kleine Struktur entwerfen, in der sich alle Infos zur Übertragung befinden,
  • Übertragung anstoßen,
  • Auf das in der Struktur vorgesehene Fertig-Flag warten,
  • ggfs. Fehlercode auswerten.
  • Next - sofern man möchte.

Gruß
Jobst

Antwort Zitieren Bearbeiten Löschen Melden Danke

Oliver S. schrieb:

AVR und TWI ist einfach … unschön. Clemens schrieb:

Der Atmega befindet sich dann in einem endlosen Reset.

Wie stellst du das fest? Oliver

Wie sieht Dein Quellcode aus?
Zum Test kannst Du den Code im Anhang probieren, den KI generierte.

"...Achtung bei Steckverbindungen während der Laufzeit: Wenn die TWI-Leitungen im Betrieb getrennt werden, kann die Hardware-TWI-Statemaschine in Endlosschleifen hängenbleiben, was oft fälschlicherweise wie ein ständiger Reset wirkt. Der untenstehende Code nutzt daher Timeouts beim Warten auf die TWI-Statusflags, um ein Blockieren des Controllers zu verhindern..."

ciao
gustav

Angehängte Dateien:
: Bearbeitet durch User
Antwort Zitieren Bearbeiten Löschen Melden Danke

Jobst M. schrieb:

Wieso das denn? Läuft völlig problemlos und nebenbei im IRQ:

...

Bis dann mal Real World Probleme auftauchen: clients, die takt stretching machen, clients, die sich ungeplant verabschieden, Multi-Master,...

Und schon begibst du dich ins Land jenseits des Datenblatts, und kannst nur noch beten.

Karl B. schrieb:

kann die Hardware-TWI-Statemaschine in Endlosschleifen hängenbleiben, was oft fälschlicherweise wie ein ständiger Reset wirkt.

Oder so.

Oliver

Antwort Zitieren Bearbeiten Löschen Melden Danke
Gast

Oliver S. schrieb:

Und schon begibst du dich ins Land jenseits des Datenblatts, und kannst nur noch beten.

Stichwort Reset. Bin bislang sehr gut damit gefahren die TWI Schnittstelle nach jeder Abfrage/Transfer zu resetten. Man kann I2C durchaus dauerhaft zuverlässig hinbekommen. Wenn es im Bereich des irgend Möglichen ist setze ich trotzdem lieber Sensoren mit weniger komplexem Interface sein.

Antwort Zitieren Bearbeiten Löschen Melden Danke
(Firma: Gast)

Moby A. schrieb:

Man kann I2C durchaus dauerhaft zuverlässig hinbekommen.

Sehe ich auch so!

Auch 2 AVR als Master machen keine Sorgen. Beim dritten AVR Master, kann es dann klemmen.

Davon ab, ist "Hot Plug" bei I2C eher nicht vorgesehen. Ohne besondere Maßnahmen wird das keiner.

Übrigens: Einen Reset, löst die TWI Hardware nicht aus! Da passiert also was ganz anderes.

: Bearbeitet durch User
Antwort Zitieren Bearbeiten Löschen Melden Danke
(Firma: Gast)

Moritz L. schrieb:

Da er mit einem klar kommt, muss er mit beliebig vielen klar kommen.

Nein!

Moritz L. schrieb:

Er kann sie ja nicht mal voneinander unterscheiden!

Richtig!

Angenomen: Ein Master (A) belegt den Bus

Dann wollen zwei weitere Master den Bus belegen. In dem Augenblick, wo A den Bus los lässt, quatschen die beiden neuen Master gleichzeitig los. Was dann zu Verklemmungen führen kann.

Die arbitration Logik der AVR scheint an der Stelle defekt zu sein.

Antwort Zitieren Bearbeiten Löschen Melden Danke

Oliver S. schrieb:

Bis dann mal Real World Probleme auftauchen: clients, die takt stretching machen, clients, die sich ungeplant verabschieden, Multi-Master,... Und schon begibst du dich ins Land jenseits des Datenblatts, und kannst nur noch beten.

Nein. Timeout - TWI-Reset - nochmal versuchen.
Wird es richtig gemacht, kannst Du nach belieben die beiden Leitungen auf GND ziehen und am Ende ist die Übertragung dennoch erfolgreich.
Und das bei gleichzeitigem weiterlaufen des main-tasks.

Edit: Tatsächlich habe ich aber noch nicht viel mit Multi-Master gemacht außer einigen kleinen Versuchen. In solchen Fällen ist anschließend immer CAN zum Einsatz gekommen.

Gruß
Jobst

: Bearbeitet durch User
Antwort Zitieren Bearbeiten Löschen Melden Danke

Vorschlag zur Güte:
An passenden stellen "wdr" einfügen.

Zitat:
"...Der Watchdog als Rettungsanker (Brute-Force): Wenn Ihr TWI-Code kein eigenes Timeout-Management besitzt und in einer Endlosschleife blockiert, wird der Befehl wdr nicht mehr aufgerufen. Der Watchdog läuft ab und startet den gesamten Mikrocontroller neu..." /Zitat

ciao
gustav

P.S.: Wundere mich also nicht, wieso zum Beispiel bei einem Analog-Digital-Comparatorprogramm der Watchdog gesetzt wird.

Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Melden Danke

Die Idee mit dem Watchdog ist auch nicht auf meinem Mist gewachsen, sondern stammt ursprünglich von Prof. Günter Schmitt,
Seite 341 ff,
ISBN Nr.:9783486587906

und nicht nur auf ASM beschränkt:
C- include: <avr/wdt.h>

Oliver S. schrieb:

Nur weiss der Client dann nichts davon, und hängt weiter fröhlich irgendwo mitten in der Übertragung.

Es gibt noch den "broadcast" Befehl ausgehend vom Master, "general call", der alle Slaves zum Zwecke des Reset anspricht. Hab's aber selber noch nicht ausprobiert. Daher mein Vorbehalt.

Zitat: "... Wichtige Einschränkungen

• Kein Pflichtstandard für alle Chips: Viele I²C-Bausteine ignorieren den General Call völlig oder unterstützen den Software-Reset-Befehl 0x06 nicht. Man muss das Datenblatt jedes einzelnen Slaves prüfen.
• Greift nicht bei Hardware-Hängern: Wenn sich ein Slave aufhängt und die Takt- oder Datenleitung blockiert (Clock Stretching oder SDA auf Low), kann der Master keinen General Call mehr abschicken.
• Alternativen: Um I²C-Slaves zuverlässig zurückzusetzen, nutzt man in der Praxis meist eine dedizierte Hardware-Reset-Leitung (Reset-Pin des Microcontrollers zu den Slaves) oder toggelt den SCL-Takt (bis zu 9 Takte senden + STOP-Condition), falls sich ein Slave verschluckt hat..."
/Zitat

ciao
gustav

: Bearbeitet durch User
Antwort Zitieren Bearbeiten Löschen Melden Danke
Thread beobachten

Antwort schreiben

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.