Controller STM32F469 in HV-Quelle resettet ungewollt

[Maik F. (Firma: ibfeew) (mf_hro)]

Hallo,
Bei einer Hochspannungsquelle wird als Controller ein STM32F469 
eingesetzt, der sowohl Kommunikation als auch Ansteuerung des 
Leistungsteils macht. Bei der Hochspannung kann es vorkommen (und ist 
gewollt), daß ein Funken an den Ausgangselektroden überspringt. Zu 
diesen Zeitpunkten stürzt der Controller nicht immer, aber ziemlich 
häufig ab: das Controllerprogramm startet komplett von vorne neu (inkl. 
Initialisierung aller Variablen). Hauptursache wird EMV-Empfindlichkeit 
sein, aber an welcher Stelle genau? Welche Ideen gibt es , warum der 
Controller abstürzen kann?

Folgendes wurde probiert/ausgeschlossen:
- Software: sehr sehr unwahrscheinlich: wenn der Leistungsteil mit einer 
konstanten Widerstandslast betrieben wird, dann läuft der Controller 
problemlos Tag&Nacht
- die im STM32F469 vorgesehenen Reset-Ursachen-Flags funktionieren 
nicht:
  das Register RCC_CSR zeigt nach dem Programmneustart 0x0000 an --> das 
sollte eigentlich nicht sein? Irgendein Flag für ein Controller-reset 
müßte doch gesetzt sein?
  spekulativ: Kann es sein, daß der Controller gar keinen reset macht, 
sondern auf andere Weise das Programm neu startet? ProgrammCounter per 
EMV auf 0 gesetzt??
- Auf die Reset-Leitung wurden schon 100nF raufgelötet. Außerdem müßte 
bei echtem externem Reset ja Bit RCC_CSR.26 (PINRSTF) gesetzt sein (mit 
reset-taster ausprobiert - wird dann im RCC_CSR.26 angezeigt)
- Hardware: Controller sitzt auf 4-layer-board, durchgehende 
Masse-Fläche direkt über dem Controller, grundlegende Layout-Sachen 
wurden beachtet (was man mit seiner Berufserfahrung halt so von sich 
behauptet)
- JTAG ist abgeklemmt, das hat beim Betrieb mit reiner Widerstandslast 
schon für Probleme gesorgt
- verlegen des Ausgangskabels mit Verlängerung, damit der HV-Funken 
räumlich etwas weiter weg erzeugt wird: 5m Verlängerungskabel scheinen 
an der Programm-Neustart-Häufigkeit nix zu ändern.
.
Bin für alle Ideen, worauf der Programmneustart zurückzuführen sein 
könnte, offen. Besonders für erklärungen, warum RCC_CRS=0x0000 nach 
Programmneustart ist.
Schönen Abend, Maik

PS/Bearbeitung: kaum abgeschickt, kommen mir die nächsten Spekulationen:
- da der angeklemmte JTAG-debugger (Segger JLink) beim Betrieb mit 
konstanter Widerstandslast Probleme gemacht hat, wäre es ja möglich, 
auch jetzt in diese Richtung zu suchen:
- kann man JTAG/SWD PA13/PA14/PB3 per GPIO-Initialisierung deaktivieren 
und danach trotzdem das nächste Programm aufspielen oder ist der 
SWD/JTAG-Port danach dauerhaft deaktiviert? Dann werde ich das morgen 
als nächsten Versuch probieren

[jo mei (Gast)]

Ich lehn' mich mal a bisserl aus dem Fenster und sage dass
beim Funken ein mächtiger Spannungs-Swing auf der Versorgung
(oder auch auf der Masse) auftritt der den Controller zum
Power-Up Neustart bringt.

Schon eine einfache ungünstige Masseschleife wird so einen
Reset zustande bringen, auf der Versorgungsspannung sicherlich
auch.

Da wir aber den Aufbau nicht kennen kann man nur spekulieren.

[M. K. (Gast)]

Das haben wir auch lang und breit bei unserem HV Impulsprüfplatz 
durchexerzieren müssen.
Es hilft im Endeffekt nur eine vollständige Schirmung und alle IOs 
galvanisch getrennt rauszuführen.

[U.G. L. (dlchnr)]

Wir hatten mal:

24V-Board-Netz --- DC/DC 24V/15V --- Wechselrichter --- Schütze


Wenn die SPS durch Aktivieren der Schütze die Drehstromlast dazu 
schaltete,
wurde der Wechselrichter auch immer zurückgesetzt.

Abhilfe schuf eine Geleichtaktdrossel auf der Eingangsseite des 24V/15V 
DC/DC Wnadlers (aus den 15V wurden dann die 5V und 3,3V der 
Wechsekrichters generiergt).

Bilder dazu:
Beitrag "Re: Welche Gleichtaktdrossel für CAN bus?"

Könnte mir vorstellen, dass auch Dir ein solchen weiterhilft - in der 
Versorgung, aber vielleicht in den Leitungen von 
Komminikationsschnittstellen (z.B. CAN).

[STM32MP1 Liebäugler (Gast)]

Maik F. schrieb:
> - Auf die Reset-Leitung wurden schon 100nF raufgelötet. Außerdem müßte
> bei echtem externem Reset ja Bit RCC_CSR.26 (PINRSTF) gesetzt sein (mit
> reset-taster ausprobiert - wird dann im RCC_CSR.26 angezeigt)

100nF erscheint mir etwas groß. Wir verbauen am Reset immer 3,9nF und 
haben seither diesbezüglich keine Probleme mehr im EMV-Labor. Bei 100n 
rauschen Signale mit sehr steilen Flanken durch (vergleiche 
Impedanzkennlinien von 100n und 3n9).

[Johannes O. (jojo_2)]

Maik F. schrieb:
> - kann man JTAG/SWD PA13/PA14/PB3 per GPIO-Initialisierung deaktivieren
> und danach trotzdem das nächste Programm aufspielen oder ist der
> SWD/JTAG-Port danach dauerhaft deaktiviert? Dann werde ich das morgen
> als nächsten Versuch probieren

Wenn du den in Software deaktivierst, dann ist nach/bei Reset wieder 
aktiv. Aber nur so lange bis der entsprechende Befehl in deiner Software 
wieder ausgeführt wird.

Achtung beim Testen: Deaktiviere den nicht per-default sondern erst nach 
nem Tastendruck, oder nach 20 Sekunden oder so. Dann kannst du den 
Controller nach nem Neustart ohne Probleme flashen.

Alternativ: Sofort JTAG/SWD deaktivieren und dann "connect under reset" 
oder ähnliches im Debugger aktivieren, dann solltest du auch wieder 
draufkommen.

Das kannst du also relativ ungefährlich mal testen. Aber schau 
sicherheitshalber ins Datenblatt wie das genau bei deinem Chip 
implementiert ist.

[Peter D. (peda)]

In der Regel haben MCs ein Statusregister, wo für jede Resetquelle 
(Power-On, Brownout, extern, Watchdog, JTAG) ein Flag gesetzt wird. 
Dieses muß man auslesen und rücksetzen.
Ist kein Flag gesetzt, dann ist die CPU durch eine Störung über 0 
gelaufen.
Wir hatten ein ähnliches Problem mit einem AVR. Die Vermutung ist, daß 
die Störung in den Quarzanschluß einkoppelt und somit ein zu kurzer 
Taktpuls entsteht. Mit Einschalten des Vorteilers 2:1 war das Problem 
verschwunden.

[Falk B. (falk)]

Maik F. schrieb:

> Initialisierung aller Variablen). Hauptursache wird EMV-Empfindlichkeit

EMV-Empfindlichkeit? Ist das sowas wie eine LCD-Display?

>   das Register RCC_CSR zeigt nach dem Programmneustart 0x0000 an --> das
> sollte eigentlich nicht sein? Irgendein Flag für ein Controller-reset
> müßte doch gesetzt sein?

Ja.

>   spekulativ: Kann es sein, daß der Controller gar keinen reset macht,
> sondern auf andere Weise das Programm neu startet? ProgrammCounter per
> EMV auf 0 gesetzt??

Eher unwahrscheinlich. Es kann aber sein, daß eine Exeption oder Trap 
ausgelöst wird und dann das passiert.

> - Auf die Reset-Leitung wurden schon 100nF raufgelötet.

Wo liegen die? Wenn, dann müssen sie SEHR nah an den Controller Pin!

> - JTAG ist abgeklemmt, das hat beim Betrieb mit reiner Widerstandslast
> schon für Probleme gesorgt

Versuch mal, dort einen Blindstecker mit Kurzschluß anzustecken.

> - verlegen des Ausgangskabels mit Verlängerung, damit der HV-Funken
> räumlich etwas weiter weg erzeugt wird: 5m Verlängerungskabel scheinen
> an der Programm-Neustart-Häufigkeit nix zu ändern.

Kann man probieren, ist aber meistens nicht das Problem, denn die 
Störung ist meist leitungsgebunden.

Man kann versuchen, den Controller und vielleicht alles ca. 1-2cm drum 
herum mit einer Kupferfolie zu bedecken und diese möglichst an vier 
Ecken auf Masse zu legen. So sieht man, ob vielleicht doch kapazitiv was 
einkoppelt. Logischerweise muss die Kupferfolie einseitig isoliert sein 
;-)

Um was für eine HV-Quelle handelt es sich? Welche Spannung macht die? 
Gibt es einen Dämpfungswiderstand am HV-Ausgang? Wie sieht der Aufbau 
insgesamt aus?

[Maik F. (Firma: ibfeew) (mf_hro)]

Hallo,
kurze Zwischenmeldung für heute:
Anlagenbild (Übersicht) im Anhang. System besteht aus Controllerplatine, 
Netzeingangsplatine, PFC-Platine, Leistungsplatine (Mosfet-Vollbrücke) 
und dann vergossener HV-Trafo. Pulsfrequenz 10...50kHz, Leistung bis 
2kW.
Läuft an Widerstandslast bis jetzt gut.
Alle Signale potentialgetrennt, die Potentialtrennung ist aber auf der 
Leistungsplatine, die Flachbandkabel tragen also 
Controller-GND-Potential und sind damit störanfällig.
Verbindung zum PC (debugging): UART-->potentialtrennung-->FTDI/USB
Dämfungswiderstand am Ausgang des HV-Trafos: nein (außer der Kabellänge, 
ca. 5m bei den aktuellen Versuchen)
Kabel bis zur HV-Spitze: koax-kabel, einseitig geerdet == Gehäuse 
HV-Trafo == PE

- zu den Anmerkungen:
100nF an Reset: es wurden auch schon 1nF/10nF probiert, keine Änderung.
Kondensator ist ca. 5cm vom Reset-pin weg. dichter geht nicht wegen:

- eingepackt in Folie:
wurde so ähnlich gemacht, einseitig Cu-kaschierte LP direkt über dem 
Controller liegend. An 4 Ecken an GND-Plane der Hauptleiterplatte 
angeschlossen. keine Verbesserung erkennbar. Vielleicht noch zuviel 
Abstand zur Hautleiterplatte? (1,5mm die aufgelegte LP + ca. 2,5mm die 
höchsten SMD-Bauelemente)

- JTAG-Pins am Stecker kurzschließen: keine Änderung

- @ Johannes:
JTAG-IO-Pins als nicht-JTAG definieren: habe ich zeitverzögert gemacht, 
hat geklappt und programmieren läßt sich uC auch noch, das war soweit 
erstmal gut.
Der JTAG-programmer meldet auch das abklemmen (nicht mehr vorhandensein) 
der JTAG-Pins, die JTAG-Zelle sollte also keinen Zugang zu externen 
IO-Störungen mehr haben.
Bringt leider trotzdem keine Besserung des Problems (uC-Neustart)

- @ Peter:
Ja, deine Beschreibung trifft es. Es sieht aus wie ein Controller-Reset, 
ohne daß ein internes RESET-Flag gesetzt ist.
Sollte theoretisch nicht vorkommen, ist aber ja aktuell eins meiner 
Probleme da ich nicht sagen kann, woher der Neustart rührt.
Aktuell Arbeitshypothese ist, daß es kein Impuls auf der Resetleitung 
ist und kein Spannungsversorgungsproblem ist. Beides sollte zu einem 
geordneten uC-reset und daher auch einem gesetzten Reset-Ursache-Flag 
führen. Im Normalfall (Gerät einschalten, Resettaster gedrückt, 
programmer-reset) werden auch die richtigen Flags angezeigt.

Für heute ist erstmal Schluß, ich muß noch irgendwas machen, wo auch ein 
Ergebnis rauskommt:).
Nächste Testpunkte (morgen):
- Alle Flachbandkabel mit Klappferriten versehen (sind bestellt)
- Evtl. die Abschirmung optimieren - vielleicht mit Cu-Klebeband?
- mal sehen, ob die JTAG/debug-zelle im Controller komplett abgeschaltet 
werden kann
- den externen Quarz (siehe Johannes) mal ausschalten und alles vom 
internen RC-Oszillator takten lassen

wenn noch mehr Ideen da sind, warum das Reset-Status-Register mit seinen 
Ursachen-Flags beim uC-Neustart nix anzeigt, immer her damit.

Schönen Tag, Maik