STM32F030C8T6: HardFault: Grund?

[Martin M. (gga)]

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

[Nop (Gast)]

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

[Ingo L. (corrtexx)]

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"
- ...

[Martin M. (gga)]

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

[Ingo L. (corrtexx)]

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.

[Gebhard R. (Firma: Raich Gerätebau & Entwicklung) (geb)]

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

[Nop (Gast)]

Ach ja, hat das Relais eine Freilaufdiode? Der Motor hat auch etwas in 
der Richtung?

[Martin M. (gga)]

Nop schrieb:
> Ach ja, hat das Relais eine Freilaufdiode? Der Motor hat auch etwas in
> der Richtung?

Relaisspule hat eine Freilaufdiode.

[Martin M. (gga)]

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.

[pegel (Gast)]

Mit dem Oszi die Spannung beobachten und auf fallende Flanke triggern 
könne helfen.

[pegel (Gast)]

Oder auf die steigende Flanke, falls die Freilaufdiode falsch rum ist. 
;)

[Til S. (Firma: SEGGER) (til_s)]

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

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

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)

[Martin M. (gga)]

Ist eine gemeinsame Freilaufdiode für 2 Relais, um die Anzahl der 
Bauteile zu minimieren.

[ennen (Gast)]

Spannung der Freilaufdiode hoch genug?
Evtl. ist die schon gestorben ;)

[Cyblord -. (cyblord)]

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.

[Bernd K. (prof7bit)]

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.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

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

[Gebhard R. (Firma: Raich Gerätebau & Entwicklung) (geb)]

>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...