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.
Angehängte Dateien:
-
dps_nr2.png
180 KB
Hi, einfach per Software 9 Pulse auf der SCL Leitung senden , dann sollte der Sensor wieder ansprechbar sein. Gruß JackFrost
>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.
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
> 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.
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
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
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.
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.
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?
Angehängte Dateien:
-
dps_def.png
170 KB -
dps_notdef.png
270 KB
Hier zwei Oszi-Bild defekt und not-defekt Nach einem powercycle verhält sich der defekte wieder ok
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
Wo hast du pull-up widerstaende ? Auch am SC0..SC7 und SD0..SD7 ? Sollten auch da benutzt werden denke ich
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
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.
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)
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.