I2C hängt, sendet manchmal nur 7 bit

[fabi (Gast)]

Hi an alle,

ich hab ein merkwürdiges Problem, bin grad ziemlich ratlos. Mein I2C 
hängt sich auf und SDA bleibt komplett auf Masse-Pegel. Man kann den Bus 
wieder zum leben erwecken, wenn man einmal kurz von Hand SCL nach Masse 
zieht, dann geht sofort die Kommunikation weiter. Ich hab mit einem 
Logik Analyzer das ganze mal mit geloggt und muss jetzt feststellen, 
dass der Master manchmal nur 7 bit sendet, SCL nach Masse geht und der 
BUS danach nicht mehr ansprechbar ist. Im Anhang gibts davon ein Bild.

Hier erstmal die Hardware:

  Master:    1x TMS320C6713B    I2C Pegel: 3,3 V
  Slaves:    6x LPC2141         I2C Pegel: 5 V

  hinter dem Master hängt noch ein Pegelwandler von TI PCA9306

  Pull-Ups verwende ich jeweils 7x 15k, das gibt dann insgesamt ~ 2k1

  Frequenz liegt um die 100 kHz

  Leitungslänge über alles 1,5 Meter, die Kapazität liegt wohl etwas
  über den 400pf aus der I2C Spezifikation von Philips


Wir haben schon ein ähnliches System aufgebaut mit Master LPC2138 und 
ATMEGA88 als Slaves, bei denen ich in 5 Jahren nie so einen Fehler 
gesehen habe. Ich denke auch, dass die Slaves LPC2141 korrekt 
eingestellt sind und sich richtig verhalten, sicher bin ich mir da 
allerdings nicht (-; Der C6713 macht mir da schon mehr sorgen, die I2C 
Schnittstelle ist hier richtig mies umgesetzt, was die Register betrifft 
und wie man sie behandeln muss. Ist nicht vergleichbar mit LPC und 
ATMEGA...

Jetzt also meine Fragen:

a. Hatte schonmal jemand diese Situation, dass nur 7 Bits getaktet 
werden und danach nichts mehr geht?

b. Ich habe schon probiert, den Master-I2C zurückzusetzen, bringt 
natürlich keinen Erfolg. Hier im Forum wurde ja schon vorgeschlagen, SCL 
manuell zu Takten, bis SDA wieder auf High ist. Der C6713 lässt das aber 
irgendwie nicht zu, wenn SDA auf low liegt. Es geht dann kein Takt raus. 
Hatte schon überlegt, den SCL Pin auf GPIO zu stellen, wie es ja auch 
bei nem LPC oder AVR geht, aber der SCL Pin hat keine Doppelbelegung. 
Wie kann ich also den I2C reseten?!

c. Hat jemand funktionierenden Code für I2C auf dem C6713? Bin mir nicht 
sicher ob ich hier alles richtig mache...

Vielen dank schonmal!

mfg fabi

[Lehrmann M. (ubimbo)]

Schaltplan !

Firmenware !

[fabi (Gast)]

Im Anhang Ausschnitte aus den Schaltplänen und den C-Sourcen von Master 
und Slaves. Ich hoffe das reicht so und ist verständlich. Den Quelltext 
zum Master hab ich nicht selber geschrieben, der stammt von einem 
Kollegen...

Was ich nicht verstehe, warum der Master manchmal nur die 7 Bits 
rausschiebt? Wenn man von Hand den Bus Lange Zeit nach Masse zieht hängt 
sich auch nichts auf und die Kommunikation läuft sofort wieder an. Egal 
ob SCL oder SDA nach Masse gezogen wird...

So ein Mist, häng da jetzt schon ne Woche an dem Problem...

thx fabi

[fabi (Gast)]

Hab da was gefunden!

http://processors.wiki.ti.com/index.php/I2cTips

External Slave Device Hanging the Bus by Holding SDA Low 

A problematic scenario can arise if the processor/I2C module gets reset 
while it is in the middle of mastering a transfer. In this scenario the 
external slave might be holding SDA low to transmit a 0 (or ACK). In this 
case it will not release SDA until it gets another falling edge on SCL. 
Even in this case it's not until it tries to transmit a '1' that it will 
actually release SDA after seeing SCL fall. The end result is that the bus 
will hang. If the I2C tries to initiate a new transfer it will hit 
an "arbitration lost" condition because SDA won't match the address it's 
sending. 

There are a couple ways to recover from this scenario. 

Option 1: For devices that mux the SCL/SDA pins with GPIO, the easiest 
thing is to configure the pins for GPIO operation and toggle SCL until the 
slave releases SDA. At this point you should be able to resume normal 
operation. 


Option 2: Many devices don't mux SCL/SDA with GPIO since the I2C I/O cells 
are often special open drain cells. A workaround has been reported to work 
even on these devices. By configuring the I2C for "free data format" and 
then reading a byte the I2C will immediately start sending clocks to input 
data (rather than trying to send an address). This can be used to free up 
the bus. 


For devices that actually boot from I2C you need to be careful about this 
scenario. Since the above workarounds rely on software they will not be 
possible if the device cannot boot! For this case you need to do something 
different. For example, if you can control the timing of the reset you 
could make sure you only reset the device when no I2C transaction is in 
progress. A different option would be to build your board such that the
processor reset power cycles the I2C EEPROM/flash (or simply resets it, 
but most EEPROMs/flashes don't have a reset pin).

Das werd ich morgen mal im Labor umsetzen und teste. Sieht aber so aus 
als ob das die Lösung ist!

mfg fabi

[Tropenhitze (Gast)]

Aber Du hast doch die Probleme im laufenden Betrieb und Dein "Master" 
bekommt nicht wiederholt einen Reset?
Ich kenne das Problem in ähnlicher Konfiguration mit anderen µCs; da hat 
der "Master" die Möglichkeit allen "Slaves" einen Reset zu geben.
Eine Alternative, wäre den "Slaves" ein Timeout zu spendieren, sodass 
diese ggf. ihre eigene IIC-Schnittstelle wieder freigeben und neu 
starten können.

Wenn der "Master" nicht richtig sendet, könnte man seine 
IIC-Schnittstelle per Software realisieren. Das wäre eine Möglichkeit 
herauszufinden, wer wo steckenbleibt.

[fabi (Gast)]

  Aber Du hast doch die Probleme im laufenden Betrieb und Dein "Master"
  bekommt nicht wiederholt einen Reset?

Das Problem kommt tatsächlich im laufenden Betrieb, reseten tut die 
Software da eigentlich nix. So gesehen ist es eine gute Frage wie es zu 
diesem Problem überhaupt kommt...

Fakt ist aber, dass ich mit einer fallenden Flanke auf SCL den Bus 
wieder zum leben erwecken kann! Ich hatte mich ja gefragt wie ich das 
vom DSP aus auslösen kann, da ja keine GPIO auf diesem Pin liegt und das 
wird genau hier beschrieben:

  Option 2: Many devices don't mux SCL/SDA with GPIO since the I2C I/O 
  cells are often special open drain cells. A workaround has been reported
  to work even on these devices. By configuring the I2C for "free data 
  format" and then reading a byte the I2C will immediately start sending 
  clocks to input data (rather than trying to send an address). This can
  be used to free up the bus.

Das werd ich morgen als erstes ausprobieren und dann mal berichten ob es 
geholfen hat!

[Frank K. (fchk)]

fabi schrieb:

> Hier erstmal die Hardware:
>
>   Master:    1x TMS320C6713B    I2C Pegel: 3,3 V
>   Slaves:    6x LPC2141         I2C Pegel: 5 V
>
>   hinter dem Master hängt noch ein Pegelwandler von TI PCA9306
>
>   Pull-Ups verwende ich jeweils 7x 15k, das gibt dann insgesamt ~ 2k1
>
>   Frequenz liegt um die 100 kHz
>
>   Leitungslänge über alles 1,5 Meter, die Kapazität liegt wohl etwas
>   über den 400pf aus der I2C Spezifikation von Philips

Ich würde vielleicht die einzelnen Busse mit einem PCA9547 oder einem 
PCA9548 entkoppeln, der damit den 9306 ersetzt und jedem Slave ein 
eigenes Bussegment spendiert.

fchk

[Peter D. (peda)]

Wenn Du Singlemaster bist, das I2C umlegen auf GPIOs und dann das I2C zu 
Fuß machen, ist kaum mehr Code als HW-I2C.
Open-drain bei GPIOs geht so, daß der Output immer low ist und nur das 
Direction-Bit geschaltet wird.
Der einzige Nachteil von SW-I2C ist, daß die CPU beschäftigt ist.

Multimaster oder Slave in SW geht aber nicht so einfach.


Peter