I2C hängt bei Stop Condition

Werner Gast 25.02.2009 19:56 #1161177

Lesenswert?

•

Hi zusammen,

vorne Weg erstmal ein paar Infos. Ich will eine I2C Verbindung zwischen 
einem Atmega 168 (Arduino NG Board) und drei Attiny 25 herstellen. Für 
den Master benutze ich die Wire Library von Arduino und beim Attiny 
Slave verwende ich den Quellcode des Appnotes 312 von AVR (siehe 
Anhang). Eingestellt ist eine Bus-Frequenz von 400kHz.

Die Kommunikation funktioniert auch grundlegend d.h. ich kann Daten 
senden und empfangen. Das Problem ist allerdings das sich der Master 
nach einiger Zeit bei der STOP Condition (in der Wire Library ist das 
die Funktion Wire.endTransmission()) aufhängt.

Meine Frage ist es möglich das der Slave den Master nicht mehr an den 
Bus "ranlässt"? Oder liegt es eher am Master?

Was ich schon versucht habe ist folgendes:
- Bus Frequenz auf 100kHz runtersetzen
- Delay von 500ms nach jedem Wire.endTransmission() eingebaut
- Rückantworten von den Slaves ausgeschaltet
- Andere Bibliotheken für den Master benutzt z.B. die von Peter Fleury. 
(Mit dieser konnte ich allerdings garnichts senden, hing schon bei der 
START Condidition)
- Die beiden while Schleifen in der Funktion twi_writeTo(..) entfernt, 
leider auch ohne Erfolg
- externe Pullup Widerstände benutzt
- und sonst noch eher kuriose, sinnlose Versuche (wie garnicht die 
endTransmission() Funktion ausführen usw. ;)

Kann es vielleicht daran liegen das die I2C-Nachrichten schnell 
hintereinander an die Slaves gesendet werden? (bei mir werden jedem 
Slave schnell hintereinander ca. fünf I2C Nachrichten von je einen Byte 
gesendet)

Langsam bin ich mit meinen Latein am Ende. Hier würde echt ein 
Oszilloskop helfen. Leider hab ich kein zur Verfügung, somit kann ich 
euch kein Timing Diagramm anbieten. :(

Gruss,
Werner

Angehängte Dateien:

I2C_Master_Slave.zip (11,7 KB)

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Tim Gast 25.02.2009 20:34 #1161217

Lesenswert?

•

▲
▼

Jeder Slave darf bei I2C die Clockleitung auf GND ziehen wenn er
mit der Verarbeitung nicht hinterher kommt. Sollte er dabei
in einer endlos schleife hängen bleiben ist dein Bus Tod.

Bei 3 Slaves dürfte es schwierig werden den schuldigen zu finden...

Bau an den Slaves doch mal Leds dran die du bei Start ein und bei
Stop ausschaltest.

Warum schickst du nicht 1x 5 byte?
Und warum 400Khz? Kabellänge?

Du solltest dir einen I2C-Sniffer zulegen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Gast Gast 25.02.2009 20:46 #1161229

Lesenswert?

•

▲
▼

Hallo,

ein Hochohmiger (kein Vcc, Pins nicht konfiguriert, Reset) Slave kann 
den I2C lahmlegen. Wie Tim schrieb sieht es für den Master dann nach 
clock stretching aus.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Werner Gast 25.02.2009 21:20 #1161276

Lesenswert?

•

▲
▼

@Tim
Axo jeder Slave hat den selben Quellcode (nur mit andere Slave Adresse 
natürlich) also wenn einer falsch läuft laufen alle falsch ;)
Bei den Slaves laufen auch Watchdog Timer (auf 60ms eingestellt) also 
wenn die Slaves sich aufängen würden, was sie nicht tuen, würde ich das 
merken. Was ich natürlich schlecht sehe ist ob sie die Leitungen ständig 
runterziehen, da werde ich das mal mit den LEDs ausprobieren.

Ich schicken die 5Bytes einzeln da es verschiedene Kommandos sind die 
aber woanders generiert werden d.h. es können auch 2-4 sein, sonst 
müsste ich alles Zwischenspeichern was schlecht wäre.

400kHz hab ich nur so genommen wie gesagt hab auch schon mit 100kHz 
versucht. Die gesamte Kabellänge beträgt ca. 30cm.

Ja ein I2C Sniffer wäre nicht schlecht.

@Gast
kein VCC oder Pins falsch konfiguriert oder ein Reset am Slave schliesse 
ich aus da es ja eine Zeit lang funktioniert, sonst dürfte es ja 
garnicht funktionieren oder?
Hmm.. aber clock streching hört sich verdächtig an. Kann also sein das 
der Slave die SCL Leitung ständig auf 0 runterzieht und diesen wieder 
nicht freigibt? Muss ich mir morgen mal genauer anschauen, aufjedenfall 
schonmal Danke für die Tipps.

Gruss,
Werner

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Tim Gast 25.02.2009 21:55 #1161326

Lesenswert?

•

▲
▼

> Bei den Slaves laufen auch Watchdog Timer (auf 60ms eingestellt) also
> wenn die Slaves sich aufängen würden, was sie nicht tuen, würde ich das
> merken.

Muss sich ja nicht aufhängen, es reicht ja wenn die state maschine
des Slaves aus dem tritt kommt.

>400kHz hab ich nur so genommen wie gesagt hab auch schon mit 100kHz
>versucht.

Ok, kommt auf die Anwendung drauf an. Ich fahr hier mit 20Khz.
Ich weiss nicht wo die grenze beim USI liegt, das verwende ich
nicht mehr.

>Die gesamte Kabellänge beträgt ca. 30cm.

Das sollte gehen.

> Ja ein I2C Sniffer wäre nicht schlecht.

Hier im Forum gibt es einige.

>Hmm.. aber clock streching hört sich verdächtig an. Kann also sein das
>der Slave die SCL Leitung ständig auf 0 runterzieht und diesen wieder
>nicht freigibt?

clock streching ist ja teil des I2C Protokolls, damit ein schneller 
Master mit einem langsamen Slave reden kann.
Wenn der Slave dabei einen hänger hat und clock nicht wieder freigibt
wartet der master bis zum nächsten Reset durch den Anwender.....
Ein Timeout im Slave und Master hilft.