Hi, Ich lese auf einem STM32F4 über die I2C Schnittstelle einen Sensor aus. Da in der nähe ein BLDC Motor läuft, kann das Störimpulse auf SDA/SCL geben und der I2C hängt sich auf, aber nur wenn ich den DMA benütze. Erst nach aktivieren des reset buttons auf dem STM32 funktioniert das ganze wieder. Ohne DMA kann ich den SCL bzw. SDA Pin ziehen und beim wieder einstecken läuft alles ohne Probleme weiter (wird durch wieder neu Initialisierung gestartet). Wie genau kann ich den DMA reseten? Wenn ich den DMA einfach neu initialisiere, scheint dies nicht die Lösung zu sein.
Sebastian T. schrieb: > scheint dies nicht die Lösung zu sein. Die Lösung ist, die Ursache des Problems zu beheben und nicht den Fehler mit herumpatchen zu übertünchen. So einfach ist das!
Ich kenne das Problem. Letztendlich lief es auf Strom aus/an schalten hinaus.
Sebastian T. schrieb: > Ohne DMA kann ich den SCL bzw. SDA Pin ziehen und beim > wieder einstecken läuft alles ohne Probleme weiter (wird durch wieder > neu Initialisierung gestartet). Was meinst Du damit? Innerhalb des Masters wird es ja wohl keinen Absturz geben(*). Er liest höchstens ein falsches Datum ein oder läuft in eine Fehlerbehandlung. Wenn der I2C abstürzt, dann ist es im Slave und Du must den Resetten, z.B. - durch Ausschalten (Versorgungsspannung) - durch einen Reset-Pin (falls er einen hat) - Durch soviele Clockimpulse, bis er fertig ist. Danach kannst Du I2C und DMA wieder aufsetzen. *) Ich hoffe, Du reagierst angemessen auf die üblichen Fehler, wie z.B. kein Acknowledge vom Slave.
Achim S. schrieb: > Ich hoffe, Du reagierst angemessen auf die üblichen Fehler, wie z.B. > kein Acknowledge vom Slave. Ja, ich habe einen "Timer" der mir ein return 1 gibt bei einem Fehlschlag. Achim S. schrieb: > - Durch soviele Clockimpulse, bis er fertig ist. Nun ja, wenn sich der Slave wirklich aufhängen würde, dann wäre doch der SDA Pin auf LOW und würde dort bleiben, oder? Das ist bei mir nie der Fall. Arduinoquäler schrieb: > Die Lösung ist, die Ursache des Problems zu beheben und > nicht den Fehler mit herumpatchen zu übertünchen. Das ist einfacher gesagt als getan, es gibt viele Störquellen (Quadcopter Umgebung) und es ist sicher zuverlässiger, wenn man auch bei einem Fehler die weitere Funktion garantieren kann.
> Innerhalb des Masters wird es ja wohl keinen Absturz geben(*). [..] > *) Ich hoffe, Du reagierst angemessen auf die üblichen Fehler, wie z.B. > kein Acknowledge vom Slave. Es kann auch der Master hängen bleiben, siehe z.B. die Anmerkung zum SWRST [0]. Wie man den zugehörigen DMA abwürgt kann ich allerdings nicht sagen. HTH [0] Kapitel 27.6.1 'I2C control register 1' im RM0090 reference manual [1] [1] http://www.st.com/resource/en/reference_manual/DM00031020.pdf
Sebastian T. schrieb: > Das ist einfacher gesagt als getan, Dann ist der I2C Bus der falsche Bus für diese Anwendung, oder die praktische Umsetzung ist so mangelhaft (ich könnte auch sagen scheisse) dass der Bus zu leicht gestört werden kann.
Arduinoquäler schrieb: > Sebastian T. schrieb: >> scheint dies nicht die Lösung zu sein. > > Die Lösung ist, die Ursache des Problems zu beheben und > nicht den Fehler mit herumpatchen zu übertünchen. Auch wenn ich dir da im Prinzip recht gebe, kann es immer mal zu einer Störung kommen. Die Software muss robust gegen sowas sein und darf das nicht mit dauerhaft lahmgelegter Kommunikation quittieren. Arduinoquäler schrieb: > Sebastian T. schrieb: >> Das ist einfacher gesagt als getan, > > Dann ist der I2C Bus der falsche Bus für diese Anwendung, oder > die praktische Umsetzung ist so mangelhaft (ich könnte auch > sagen scheisse) dass der Bus zu leicht gestört werden kann. Ok, mal angenommen, es wird so umgebaut, dass er nur noch schwer zu stören ist, und es kommt trotzdem mal eine Störung vor. Was dann?
Achim S. schrieb: > *) Ich hoffe, Du reagierst angemessen auf die üblichen Fehler, wie z.B. > kein Acknowledge vom Slave. Wie soll er, der DMA redet mit dem Slave und hat bestimmt keinen Plan, was er tun soll, wenn mitten in der Message ein NAK kommt. MfG Klaus
g457 schrieb: > Es kann auch der Master hängen bleiben Wenn ich mit dem Debugger das ganze verfolge, dann bleibt der Master (STM32) nicht hängen. Ich initialisiere alles neu und versuche etwas zu senden, doch der I2C scheint die ganze Zeit busy zu sein. Dann wiederholt sich das ganze.
1 | while(I2C_GetFlagStatus(I2C2, I2C_FLAG_BUSY)) { |
2 | if (--timeout == 0) { |
3 | return 1; //es kommt dann immer zu return 1 |
4 | }
|
5 | }
|
Rolf M. schrieb: > Ok, mal angenommen, es wird so umgebaut, dass er nur noch schwer zu > stören ist, und es kommt trotzdem mal eine Störung vor. Was dann? Ok, mal angenommen, es fliegt aus dem All ein Teilchen ins RAM deines Computers und trifft genau eine Speicherzelle deines laufenden Kernels .... ... oder in klaren Worten: man kann eine Hardware so bauen das sie zuverlässig funktioniert.
Ok, ich habe es hinbekommen, das Problem war, dass ich den TX Stream nicht wieder aktiviert hatte mit DMA_Cmd(DMA1_Stream7, ENABLE); beim erneuten initialisieren. Danke und Grüsse, Sebastian
:
Bearbeitet durch User
Arduinoquäler schrieb: > Rolf M. schrieb: >> Ok, mal angenommen, es wird so umgebaut, dass er nur noch schwer zu >> stören ist, und es kommt trotzdem mal eine Störung vor. Was dann? > > Ok, mal angenommen, es fliegt aus dem All ein Teilchen ins > RAM deines Computers und trifft genau eine Speicherzelle > deines laufenden Kernels .... Es gibt nicht nur schwarz oder weiß. Nur weil es bestimmte Störungen gibt, gegen die man nichts tun kann, heißt das nicht, dass man seine Software nicht robust gegen die machen sollte, gegen die man sehr wohl was tun kann. Übrigens sind tatsächlich Systeme, die besonders zuverlässig sein müssen, mit Fehlerkorrektur für den RAM ausgestattet.
http://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf siehe solution 1 Uusere I2C-Implementation schaut sich vor jeder Kommunikation die Busleitungen an und wenn nicht beide auf "high" sind so startet er die entsprechende Takterei. Beim STM32 musst du dazu die Pins zum GPIO umkonfigurieren und nach Abschluss der Sequenz wieder zurück zur alternate function wechseln. Übrigens wieder mal ein schönes Beispiel, weshalb man die ganzen HAL bzw. Periph. Library-Gedöns von ST NICHT benutzen sollte wenn man vorhat industriell zu programmieren. Besser ist es nach altehrwürdiger E-Technikertradition: Datenblatt lesen, Hirn einschalten und entsprechend implementieren. Spätestens ab hier kommen die Informatiker eh nicht mehr mit :-) (Sorry, der Satz musste sein: wir hatten gerade eben Teambesprechung)
Rolf M. schrieb: > Übrigens sind tatsächlich Systeme, die besonders zuverlässig sein > müssen, mit Fehlerkorrektur für den RAM ausgestattet. Wenn der Windows Kernel läuft, dann tut er das sicherlich an einer beliebigen Stelle im stinknormalen SDRAM des PC. Und soweit ich es überblcken kann haben 99% aller Windows-Systeme SDRAMs in ihrer Hardware die kein Parity Check oder ECC vorgesehen haben. Ich habe mich darüber seit Urzeiten des PC gewundert aber die Masse an funktionierenden Systemen zeigt dass es irgendwie geht .... Wenn das geht, dann sollte man den I2C Bus auch so hinkriegen können .... .... aber Patchen, Herumpfriemeln, Übertünchen ist ja viel cooler.
Arduinoquäler schrieb: > Rolf M. schrieb: >> Übrigens sind tatsächlich Systeme, die besonders zuverlässig sein ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> müssen, mit Fehlerkorrektur für den RAM ausgestattet. ^^^^^^ > > Wenn der Windows Kernel läuft, dann tut er das sicherlich an Ich habe dir da oben mal was markiert, was in totalem Widerspruch zu deinem Beitrag steht. Wenn man schon Geld in fehlerkorrigierende Hardware reinsteckt, dann konkterkariert man diese Maßnahmen (die ja die Verfügbarkeit des Gesamtsystems erhöhen sollen) tunlichst nicht durch den Einsatz von Windows.
Ich glaub, wir schweifen etwas vom Thema ab. Was ich sagen wollte (und auch gesagt hab) ist, dass ich es für sinnvoll halte, Software fehlertolerant auszulegen, also so, dass sie mit Fehlern adäquat umgeht, wo das möglich ist. Manch einer mag das "Patchen, Herumpfriemeln, Übertünchen" nennen, ich nenne es robustes Software-Design. In der Automobilbranche wird sehr viel Aufwand genau in dieses Thema gesteckt, denn im Auto darf nicht einfach alles ausfallen bis das nächste Mal die Batterie abgeklemmt wird, nur weil auf dem Bus mal ein Bit gekippt ist. Vielmehr haben alle Steuergeräte in solchen Fällen auf genau definierte Art und Weise zu reagieren.
Rolf M. schrieb: > Software > fehlertolerant auszulegen, also so, dass sie mit Fehlern adäquat umgeht, > wo das möglich ist. Manch einer mag das "Patchen, Herumpfriemeln, > Übertünchen" nennen, ich nenne es robustes Software-Design. Das sind zwei ganz verschiedene Dinge. Bei einer "schlechten" HW dutzende ADC Werte mitteln und dann an das Ergebnis glauben, Nachrichten mehrfach schicken und Mehrheitsentscheidungen treffen ist das eine, eine anständige Fehlerbehandlung das andere. MfG Klaus
Klaus schrieb: > Bei einer "schlechten" HW > dutzende ADC Werte mitteln und dann an das Ergebnis glauben, Nachrichten > mehrfach schicken und Mehrheitsentscheidungen treffen ist das eine, eine > anständige Fehlerbehandlung das andere. Nun, "Arduinoquäler" fand es ja anscheinend nicht nötig, dass die Software damit klar kommt, wenn auf dem I²C mal ein Übertragungsfehler passiert und findet es völlig in Ordnung, wenn die Kommunikation dann komplett zusammenbricht und nicht mehr funktioniert, bis man das ganze von der Versorgung trennt und wieder anschließt. Ich sehe das anders, und darauf bezog sich auch meine Antwort. Natürlich muss man auch die Hardware so bauen, dass Störungen möglichst nicht auftreten. Zusätzlich sollte man aber auch die Software dagegen absichern, statt einfach zu sagen: "Ich hab ja in der Hardware schon alles getan, also können Fehler ja eh nicht mehr auftreten".
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.