Debuggen bei EMV-Tests

Während EMV mach ich Diagnose nur über CAN/LIN z.B. XCP. Also nur über 
die bereits vorhandene Schnittstellen.

Wann soll denn wirklich Debuggen Sinn machen? Ich überprüfe bei der EMV 
Messung ja keine Software.

Es gäbe ja auch noch galvanische Trennung zwischen debug Probe und DUT. 
Zb von segger.

Kann natürlich trotzdem sein dass dir die Pulse die Kommunikation an 
sich stören...

Zur Not wirklich tracen per Output..

pcuser schrieb:
> ihr euch per Debugger aufschalten müsst?

Was willst du debuggen, wenn es ungestört läuft ?

Offenbar ein elektrisches Problem.

Ich musste mich während einer EMV Messung noch nie per Debugger 
aufschalten. Würde wahrscheinlich auch das Messergebnis verfälschen. 
Daher alle Ausgaben nur über vorhandene Schnittstellen oder sonst eben 
mit Sonder-SW in den Test die einem Debug Daten liefer kann und diese 
z.B. im EEPROM speichert.

pcuser schrieb:
> Ich habe hier zwar einen USB/LWL-Wandler

Ist es das Teil von Corning? Die haben so einen USB-LWL Wandler, 
allerdings total dämlich gemacht, da zwar die Signale auf LWL gehen, 
zwei Kupferdrähte zur Versorgung des Empfängers liegen aber parallel. 
Dazu keine Möglichkeit der Lokalspeisung des Empfängers.

pcuser schrieb:
> Hallo,
>
> was verwendet ihr, wenn euer Prüfling sich bei EMV-Tests (z.B.
> Burst/Surge) sich problematisch zeigt und ihr euch per Debugger
> aufschalten müsst?
>
> Ich habe hier zwar einen USB/LWL-Wandler, jedoch verabschiedet sich die
> USB-Verbindung (oder der ST-Link) trotzdem.
>
> Beispielkonfig:
> Laptop <-----> USB/LWL <-----> ST-Link <-----> DUT
>
> Wie macht ihr das?

Servus,

USB und Burst ist schwierig (um das mal nett auszudrücken). Deshalb 
werden z.B. EMV-Generatoren von EM-Test per IEEE-488 und nicht per USB 
angesteuert. Ich würde auch versuchen zwischen ST-Link und DUT (wie oben 
beschrieben) eine (lange) LWL-Verbindung zu bekommen. Kann man beim 
ST-Link die Frequenz zum DUT einstellen? Wenn ja, dann auf geringst 
mögliche Frequenz wechseln.
Schon mal Ferrite auf die USB-Leitung oder auf die Leitung zwischen 
ST-Link und DUT geklemmt (entweder Klappferrite oder gleich eine Zange 
auf die USB-Leitung)?

Weitere Ideen:
Wie sieht die Masse-Verbindung des Systems aus?
Die Burst-Spannung mal reduziert und in kleinen Schritten steigern. 
Vielleicht sieht man schon erste Fehler, ohne das das ganze System 
aussteigt.


Aber mal ehrlich: Muß es wirklich der Debugger sein? Kannst Du nicht 
Debug-Ausgaben per UART rausschicken? Dafür gibt es genug Umsetzter auf 
LWL.

Gruß

Robert

Gerd E. schrieb:

> Wenn es zu viele Daten werden als daß Du das mit dem bloßen Auge
> erkennen kannst: UART über eine IR-LED ausgeben, wie bei den
> IR-Fernbedienungen mit z.B. 38 kHz moduliert. Decodieren dann mit nem
> IR-Empfänger.

Aber eine LED mit Schraubgewinde nehmen. Agilent HFBR-1402 oder sowas. 
Dafür liegen in der EMV-Kammer schon so praktische orange Glasfasern 
bereit, die man dranschrauben kann.

Die Modulation muss nicht sein, ich schiebe meine Telemetrie mit 1 
Mbit/s im Basisband durch die Faser. Also Schaltung wie im Datenblatt, 
die LED leuchtet bei High vom UART-Pin und ist aus bei Low, und 
empfängerseitig geht das Ganze auf ein FTDI-Kabel zum PC.

Wenn Burst / Surge die MCU in die Ecke hängt, wird der Debugger Dir auch 
nicht helfen.
Conducted / radiated Messung ist hinfällig wenn Du etwas so veränderst 
das es nicht mehr der Serie entspricht. Dazu zähle ich mal den Debugger.

Burst / Surge ist eigentlich das Unproblematischte.
In positive Richtung muss man nur die Energie vernichten, ins negative 
muss zusätzlich der Buffer Cap (der per Diode abgekoppelt ist!), lange 
genug versorgen bis das Ereigniss vorbei ist.
Zu schwache Dimensionierung ist beim Surge zumindest dauerhaft gut zu 
erkennen. Kaputt oder geht. Viel mehr ist da nicht.
Viel einfacher zu finden als so manch andere EMI Sauerei.

HF susceptibility ist zwar fies, aber auch da sehe ich keinen Debugger 
als mögliche Lösungshilfe.

pcuser schrieb:
> Ich habe hier zwar einen USB/LWL-Wandler, jedoch verabschiedet sich die
> USB-Verbindung (oder der ST-Link) trotzdem.

Also ST Link an der gestörten MCU, an der gleichen VCC?
Was lässt Dich vermuten das die MCU dann überhaupt noch was tut, bzw. 
warum sollte der STlink das Ereigniss durchstehen, wenn die MCU das 
schon nicht packt?

Deux schrieb:
> Ich überprüfe bei der EMV
> Messung ja keine Software.
Oh doch.
Die Software ist durchaus Teil der Messung, kann selbst eine Störursache 
sein oder wie in dem Fall des TO der schlüssige Beweis das hier kein 
Watchdog triggert der die Kiste aus dem Nirvana zurückholt.
Oder die Brown out detection ist nicht aktiv, die MCU kommt in Bereiche 
in denen sie nicht mehr zuverlässig arbeitet und führt zufälligen Cide 
auszuführen.
Genau sowas hat uns mal eine große Rückholaktion bescherrt, weil die 
Softies das für nicht relevant hielten.

Software die Leistungsteile ansteuert würde ich sogar als ganz 
wesentlich für das Bestehen der Prüfung ansehen.
Schön mit fixer PWM ohne spread sprectrum, mit knappen Brückentimings 
rumtackern und der Test ist gelaufen.