Forum: Mikrocontroller und Digitale Elektronik I2C-Sensoren hinter I2C-Switch nicht mehr ansprechbar


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von stm32 (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe eine Stm32-Schaltung, wo 8 Druck-Sensoren (Infineon DPS 310) 
hinter einen I2C-Switch (TI TCA9548) bedient werden.
D.h. ich lese der Reihe nach Druck-Werte aus.

Nach mehreren Resets hintereinander (Power on, aber auch SW-Resets), 
kann ich plötzlich einen Sensor nicht mehr ansprechen.

Man sieht das auf dem Bild:
Grüne-Linie = SDA, da wird erst Start, und dann 0x70 gesendet (=die I2C 
Adresse des TCA), im 2. Byte 0x02 (=der 2. Sensor hinter dem Switch).
Im Grid ganz rechts, ab ca 160ms sollte die SDA nach high gehen, aber 
das tut sie nicht.
Das i2C Flag "I2C_ISR_BUSY" geht nicht auf Reset und ein Timeout 
passiert.

Wenn ich mehrmals einen SW-Reset mache, bekomme ich immer das gleiche 
Fehlerbild, d.h. der gleiche Sensor hinter dem Switch funktioniert 
nicht.

Ziehe ich die Spannung komplett ab, dann geht es ca 10x, bis irgendein 
anderer Sensor das gleiche Fehlerbild hat.

Wo kann ich suchen? SW/HW?
Ich vermute, dass bei häufigen Resets irgendein Sensor in einen 
bad-State kommt, wo er nur durch Power-off wieder rauskommt.
Die 8 Sensoren haben leider keine Reset-Leitung, ich kann sie nicht vom 
uC aus resetten.

von Bastian W. (jackfrost)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

einfach per Software 9 Pulse auf der SCL Leitung senden , dann sollte 
der Sensor wieder ansprechbar sein.

Gruß JackFrost

von holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>einfach per Software 9 Pulse auf der SCL Leitung senden , dann sollte
>der Sensor wieder ansprechbar sein.

Wenn der Slave Clockstretching macht wird das nichts.
Der hält SCL einfach auf GND.

von Bastian W. (jackfrost)


Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
>>einfach per Software 9 Pulse auf der SCL Leitung senden , dann sollte
>>der Sensor wieder ansprechbar sein.
>
> Wenn der Slave Clockstretching macht wird das nichts.
> Der hält SCL einfach auf GND.

Auf dem Bild ist aber SCL High.
Vermutlich zieht der Sensor SDA auf Low da der Sensor aktuell ein Bit 
auf den
Bus legt.

Bei meinem xMega war das der Fall wenn ich ihn neu geflashed hatte und 
der Reset vom Programmer während einer Übertragung auf den I2C gekommen 
ist. Der
FRAM hatte dann das Bit noch auf dem Bus da noch nicht alle 9 Takte 
gekommen waren.

Gruß JackFrost

von stm32 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Vermutlich zieht der Sensor SDA auf Low da der Sensor aktuell ein Bit
auf den Bus legt.

SDA bleibt aber sehr lange Zeit (>100ms) auf low, auf dem Bild nicht 
sichtbar bei anderer Auflösung schon.

von Bastian W. (jackfrost)


Bewertung
0 lesenswert
nicht lesenswert
stm32 schrieb:
>> Vermutlich zieht der Sensor SDA auf Low da der Sensor aktuell ein Bit
> auf den Bus legt.
>
> SDA bleibt aber sehr lange Zeit (>100ms) auf low, auf dem Bild nicht
> sichtbar bei anderer Auflösung schon.

Am Ende von deinem Bild ist SDA low und SCL High. Normal würdest du hier 
dann Start + Adresse senden wollen , oder ?

Gruß JackFrost

von Klaus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bastian W. schrieb:
> einfach per Software 9 Pulse auf der SCL Leitung senden , dann sollte
> der Sensor wieder ansprechbar sein.

Der Klassiker. Genau so!

MfG Klaus

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
stm32 schrieb:
> Nach mehreren Resets hintereinander (Power on, aber auch SW-Resets),
> kann ich plötzlich einen Sensor nicht mehr ansprechen.

Das muß so sein, wenn das Reset einen gerade laufenden I2C-Transfer 
abwürgt und der Slave gerade ein low-Bit sendet.

Ich kenne keinen HW-Master, der sowas auflösen kann. Du mußt die Pins 
als IO konfigurieren und zu Fuß SCL 9* takten.

von stm32 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke. Ja, eigentlich logisch.
Den Software-Reset habe ich korrigiert, der wird nach einer Anforderung 
erst aufgerufen (NVIC_SystemReset), sobald alle I2C-slaves im Idle-Mode 
sind.
Und schon funktioniert es ...

Die HW-Resets abzusichern ist aber umfangreicher.

Beitrag #5477324 wurde vom Autor gelöscht.
von stm32 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ok, danke für Eure Vorschläge.
Es hat zunächst wunderbar funktioniert.

Wenn ich einen Sensor nicht ansprechen konnte, schaltete ich die SDA,SCL 
Leitungen auf GPIO-Output, gab auf SCL die Toggle-Sequenz aus, und es 
ging.

Aber nur in 99% in aller Fällen.

Es gab seltene Fälle, da konnte ich den Sensor auch nicht nach der 
Toggle-Sequenz ansprechen, der restliche Bus war aber funktional.
Der defekte Sensor hat die Bus-Botschaften mitgehört, aber kam nie in 
einen Zustand, wo er ansprechbar war.

Und zwar steigt an der Stelle aus:
Ich habe den Ausschnitt aus der I2C-Statemachine dargestellt.
Bei Zustand "*pstat==2" startet der Transfer. Der erste Schritt kann 
ausgeführt werden, bleibt aber dann im " *pstat == 3 " hängen bis zum 
Timeout.
1
if (*pstat == 2)
2
{
3
  if (I2C_GetFlagStatus(I2Cx, I2C_ISR_BUSY) == RESET)
4
  {
5
    /* Configure slave address, nbytes, reload, end mode and start or stop generation */
6
    I2C_TransferHandling(I2Cx, address<<1, 1, I2C_SoftEnd_Mode, I2C_Generate_Start_Write);
7
    (*pstat)++;
8
  }
9
}
10
else if (*pstat == 3)
11
{
12
  if (I2C_GetFlagStatus(I2Cx, I2C_ISR_TXIS) != RESET)
13
  {
14
    //HIER KOMMT ER NICHT AN
15
    I2C_SendData(I2Cx, regaddress);
16
    (*pstat)++;
17
  }
18
}

Nur durch einen power-cycle war er wieder funktionsfähig.
Es handelt sich um Infineon DPS310.
Bei den anderen verwendeten Sensoren in diesem Steuergerät gibt es keine 
Aussetzer.

Ich habe noch keine Idee, wie ich so eine Situation retten kann. (Ich 
kann die Spannung der Sensoren nicht ausschalten)

Ideen?

von stm32 (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier zwei Oszi-Bild
defekt
und not-defekt

Nach einem powercycle verhält sich der defekte wieder ok

von TK (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nur mal eine Frage zu den Diagrammen:
1) Mach mal bitte eine Aufnahme mit einem gezoomten Ausschnitt von 
SCL/SDA. Ich würde gerne mal die exakten Zeiten und Flanken sehen. Dann 
auch bitte mal die SCL und SDA direkt untereinander positionieren (z.B. 
bei Deinem dps_def.png).

2) Entweder stimmt die Oszi Anzeige der Pegel nicht, oder falls doch, 
hast Du ein wirkliches Problem, wenn die Slaves nicht alle mit 1V 
arbeiten.

Gruß
TK

von Patrick C. (pcrom)


Bewertung
0 lesenswert
nicht lesenswert
Wo hast du pull-up widerstaende ? Auch am SC0..SC7 und SD0..SD7 ? 
Sollten auch da benutzt werden denke ich

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
stm32 schrieb:
> Es handelt sich um Infineon DPS310.

Nun, das ist kein Sensor in Hardware, sondern ein programmierter DSP.
Im Timing ist zu sehen, daß er Clock-Stretching benutzt.
Du darfst ihn also nicht einfach takten, sondern mußt nach jedem Wechsel 
von SCL von low nach hochohmig erstmal warten, bis SCL auch wirklich 
high ist.
Dann klappt das auch mit dem Freitakten.
Und auch das Master-I2C muß Clock-Stretching beachten, sonst kann er 
sich auch dabei aufhängen.

Siehe: Figure 11  I2C timing diagram

von stm32 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der Fall tritt sehr selten auf, ca 1x pro 400 Resets.
Und es dauert etwas, die Bilder (single-shot) zu machen.

Bei beiden Bildern sieht man die I2C-Adresse (0x77), das R/W-Bit, 
korrekt.
Nur dann gibt der korrekte Sensor das ACK-Bit, der andere nicht.



> von SCL von low nach hochohmig erstmal warten, bis SCL auch wirklich
high ist.

Ok, das habe ich nicht gemacht. Ich habe sehr langsam getaktet mit 32Hz 
(d.h. Pegelwechsel mit 64Hz), und bin davon ausgegangen, dass das 
langsam genug ist.

Auch vermutete ich, dass es jetzt ein anderes Problem ist.
In den Fällen, wo ich mit Freitakten erfolgreich war, hat der Slave SDA 
auf low gehalten, und der ganze I2C-Bus war nicht mehr funktional. 
(siehe Bild vom Eingangspost)
Das konnte ich immer mit Freitakten lösen.

Hier geht SDA sofort wieder auf High, und der restliche Bus bleibt 
funktional.

von stm32 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Habe das Freitakten geändert, d.h. 1. nach jeden Downpuls: von Ausgang 
zu Eingang (hochohmig) schalten,
2. dann schauen, wann Pegel nach high geht,
3. auf Ausgang schalten, dann wieder einen Down-Puls.
insgesamt 9x

Aber Problem noch nicht gelöst.
Im Datenblatt vom DPS310 steht beim I2C-Interface, dass SCL-Pulsbreite 
mindestens 20% sein soll.
Aber die ist in meinem Fall wesentlich kleiner, vermutlich 5-10%. (siehe 
Bilder)

Ich kann auch kein Register beim Stm32F0 erkennen, wo man einstellen 
könnte.
(???)

(Bzgl anderen Fragen: Die Spannungspegel stimmen alle, 3.3V, in den 
Oszi-Bildern ist das skaliert)

von TK (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

TK schrieb:
>Mach mal bitte eine Aufnahme mit einem gezoomten Ausschnitt von
>SCL/SDA. Ich würde gerne mal die exakten Zeiten und Flanken sehen.

Du schriebst:
>Im Datenblatt vom DPS310 steht beim I2C-Interface, dass SCL-Pulsbreite
>mindestens 20% sein soll.
>Aber die ist in meinem Fall wesentlich kleiner, vermutlich 5-10%. (siehe
>Bilder)
>(Bzgl anderen Fragen: Die Spannungspegel stimmen alle, 3.3V, in den
>Oszi-Bildern ist das skaliert)
Oder hast Du einen 1:10 Tastkopf im Einsatz?

Fazit:
Nach doch noch mal Bilder mit ZOOM auf 8 Takte / Daten

Gruß
TK

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.