Hallo, ich habe ein STM32F030C8T6, der ab und zu in den Hard-Fault geht. Der STM32 schaltet ein Relais und danach geht er in den Hard-Fault. Vor und nach dem Schalten wird ein Diagnosebit ins EEPROM geschrieben, um den Fehler zu lokalisieren. Beim Fehler wird das zweite Bit (nach Ansteuern des Relais) nicht gespeichert. Das Relais schaltet einen 230V-Motor mit ca. 0,8A. Das Problem ist von äußeren Einflüssen abhängig. Im Entwicklungslabor funktioniert es ohne Probleme (ohne Last am Motor). Im Prüffeld (mit geringer Last am Motor) tritt der Fehler auf, aber mal nach 1 Stunde, dann auch mal wieder erst nach mehreren Tagen. Eventuell abhängig durch Störungen im Stromnetz durch Prüffeld oder benachbarte Fertigung. Die SWD-Leitung läuft mit ca. 20 cm Länge durch die Platine. Es ist kein externer Pull-Up am SWDIO dran. Ob es daran liegen kann? Das Problem am Eingrenzen des Fehlers ist, daß er meist tagelang nicht auftritt. Debuggen ist nicht möglich, da die Schaltung netzbehaftet ist. Selbst mit Trenntrafo ist es mir zu gefährlich, den Debugger anzuschließen. Leider gibt es keine Möglichkeit, den SWD mit Sicherer Trennung zu betreiben. Es gibt lediglich ein Teil mit Basisisolierung von Segger: https://www.segger.com/products/debug-probes/j-link/accessories/isolators/j-link-swd-isolator/ Gruß Martin
Gast
#6009955
Martin M. schrieb: > Debuggen ist nicht möglich Eingeschränkt doch, denn der Hardfault erlaubt zumindest einen Rückschluß, an welcher Adresse er aufgetreten ist. Das kriegste über SP+0x18 raus, was Du ins EEPROM schreiben kannst. Zusammen mit dem Mapfile kannst Du dann ermitteln, in welcher Funktion das war. Interessant ist v.a., ob das immer an derselben Adresse passiert oder nicht. https://community.arm.com/developer/ip-products/system/f/embedded-forum/3257/debugging-a-cortex-m0-hard-fault
Das Übliche halt: - 100nF Abblockung vorhanden? - Alle offenen IOs zu Ausgängen umgeschaltet? - Reset mit nem 10nF gegen GND abgespannt? - Kommen irgendwelche Signale über ne lange Leitung aufs Board? - Spannungen "sauber" - ...
Ingo L. schrieb: > Das Übliche halt: > - 100nF Abblockung vorhanden? > - Alle offenen IOs zu Ausgängen umgeschaltet? > - Reset mit nem 10nF gegen GND abgespannt? > - Kommen irgendwelche Signale über ne lange Leitung aufs Board? > - Spannungen "sauber" > - ... - 100nF Abblockung vorhanden? => ja - Alle offenen IOs zu Ausgängen umgeschaltet? => nein. Warum? - Reset mit nem 10nF gegen GND abgespannt? => sind sogar 100nF dran - Kommen irgendwelche Signale über ne lange Leitung aufs Board? => ja, die 230V-Zuleitung geht über einen extrem hochohmigen Spannungsteiler auf einen Input. - Spannungen "sauber" => bisher keine Auffälligkeiten erkannt
Martin M. schrieb: > - Alle offenen IOs zu Ausgängen umgeschaltet? => nein. Warum? Weil offene Eingänge böse und undefiniert sind und sich hier evtl. Störsignale einkoppeln können und den µC zum Absturz bringen können. > ja, > die 230V-Zuleitung geht über einen extrem hochohmigen Spannungsteiler > auf einen Input. Hier sollte man auch mit etwas C abstützen um die Störungen auf der Leitung zu entstören. Man unterschätzt gerne mal das Störpotential langer Leitungen und offener Eingänge.
Das hört sich nach einem EMV Problem an. Die SWD Leitungen einmal eher niederohmig an GND legen, und/oder überhaupt im Code abschalten. Das Relais ist natürlich suboptimal, ein Triac wär jetzt viel besser gewesen. Einen Varistor am Motoranschluß und ein RC Glied parallel zum Schaltkontakt des Relais sollte einiges verbessern. Grüsse
Gast
#6010023
Ach ja, hat das Relais eine Freilaufdiode? Der Motor hat auch etwas in der Richtung?
Nop schrieb: > Ach ja, hat das Relais eine Freilaufdiode? Der Motor hat auch etwas in > der Richtung? Relaisspule hat eine Freilaufdiode.
Gebhard R. schrieb: > Das > Relais ist natürlich suboptimal, ein Triac wär jetzt viel besser > gewesen. Einen Varistor am Motoranschluß und ein RC Glied parallel zum > Schaltkontakt des Relais sollte einiges verbessern. der HardFault kommt extrem schnell nach dem Schalten des Relais. Da kann quasi noch kein Motorstrom geflossen sein.
Gast
#6010314
Mit dem Oszi die Spannung beobachten und auf fallende Flanke triggern könne helfen.
Gast
#6010317
Oder auf die steigende Flanke, falls die Freilaufdiode falsch rum ist. ;)
Vielleicht hilft das auch wenn es sich eher nach einem Hardwareproblem anhört: Analyzing HardFaults on Cortex-M CPUs (AN00016) https://www.segger.com/downloads/application-notes/AN00016
Martin M. schrieb: > Debuggen ist nicht möglich, da die Schaltung netzbehaftet ist. Selbst > mit Trenntrafo ist es mir zu gefährlich, den Debugger anzuschließen. > Leider gibt es keine Möglichkeit, den SWD mit Sicherer Trennung zu > betreiben. Wir entwickeln gerade genau für solche Fälle einen Funk betriebene Debug Probe. Wir haben noch keinen STM32 Support implementiert und unterstützen für die derzeitige Test-Phase nur OS/X. Aber vielleicht finden wir aber trotzdem eine Möglichkeit der Zusammenarbeit? (->DM)
Ist eine gemeinsame Freilaufdiode für 2 Relais, um die Anzahl der Bauteile zu minimieren.
Angehängte Dateien:
-
Relaisschaltung.png
(7,9 KB)
Gast
#6010334
Spannung der Freilaufdiode hoch genug? Evtl. ist die schon gestorben ;)
Torsten R. schrieb: > Wir haben noch keinen STM32 Support implementiert und > unterstützen für die derzeitige Test-Phase nur OS/X. Aber vielleicht > finden wir aber trotzdem eine Möglichkeit der Zusammenarbeit? (->DM) Entwickelt ihr als erstes für die Nische? Kein STM32 und nur OS/X Support? Wen oder was will man damit anlocken? Debuggende Arduino Hipster.
Martin M. schrieb: > Die SWD-Leitung läuft mit ca. 20 cm Länge durch die Platine. Es ist kein > externer Pull-Up am SWDIO dran. Ob es daran liegen kann? Also ist eine Steckverbindung für den Debuganschluß auf der Platine? Mach mal nen Blindstecker bei dem DIO, CLK und Reset hart auf VCC gelegt werden, steck den drauf und dann probiers nochmal. So lange Antennen die hochohmig in der Luft hängen und an nackte Eingänge gehen sind nicht gut.
Cyblord -. schrieb: > Entwickelt ihr als erstes für die Nische? Kein STM32 und nur OS/X > Support? Wen oder was will man damit anlocken? Debuggende Arduino > Hipster. Hallo Cyblord, OS/X ist meine Entwicklungsplatform und dem entsprechend entwickel ich erst einmal dafür. Da GDB-Server und Flashtools erst einmal CLI-Tools sind, ist die Portierung auf Windows dort nicht besonders aufwändig. Der einzig große Unterschied bei den Systemen (Windows, OS/X, Linux) ist der Bluetooth-Stack. Den werden wir aber ggf. auch anfänglich erst einmal raus nehmen, in dem wir die Debug-Probe mit einem eigenen BLE-Dongle mitliefern. Der Unterschied von STM32 zu anderen ARM basierten Controllern ist "nur" der Flash controller. Wir unterstützen schon nrf52 und SAM4S. Damit kann man zumindest schon mal alle Cortex-M4/F controller Debugger. schöne Grüße, Torsten
>der HardFault kommt extrem schnell nach dem Schalten des Relais. Da kann >quasi noch kein Motorstrom geflossen sein. Wie willst du denn das wissen, oben hast du gesagt, dass im Betrieb wegen nicht-Netztrennung der Debugger nicht angeschlossen werden kann. Wenn das Zeug im Labor tagelang ohne Last läuft, wird es sich eher nicht um ein Softwareproblem handeln. Wie gesagt, hohe du/dt und di/dt am Netz durch Entstörmaßnahmen vermeiden. Du kannst das Relais vlt. probehalber auch durch ein Halbleiter-Relais ersetzen. Wenn's dann läuft, weisst du woher das Problem kommt...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.