Zusammenfassung: Der ESD-Schutz hat funktioniert, und das Gerät ist trotzdem durch die Prüfung gefallen. In einem unserer Dual-Brain-Designs hat eine Linux-CPU den Modus eines MCU über drei GPIO-Leitungen gesetzt, und ein Modus nutzte den Code 111. Bei der ESD-Prüfung traf die Entladung diese Leitungen nie direkt, aber sie störte das ganze Gerät und konnte alle drei Leitungen gleichzeitig auf High ziehen. Der MCU las 111 und wechselte von selbst den Modus. Das ist eine Änderung des Betriebszustands und damit ein Verstoss gegen Bewertungskriterium B. Die Lösung lag in der Firmware, nicht in der Hardware: Wir haben diesen Modus auf einen gemischten Code wie 101 gelegt. Hier steht, warum das funktioniert, warum ein Design überhaupt bei GPIO-Modusleitungen landet und was Sie in Ihrer eigenen Firmware prüfen sollten.
Was passiert ist
Das Design hatte zwei Gehirne: eine CPU mit Linux und daneben einen MCU. Die CPU teilte dem MCU über drei GPIO-Leitungen, MODE2, MODE1 und MODE0, mit, in welchem Modus er sein soll. Der MCU las die drei Pegel als Code und handelte danach. Im Normalbetrieb lag auf den Leitungen ein Code wie 010 für einen Modus. Ein anderer Modus nutzte den Code 111.
Dann kam die ESD-Prüfung. Die Entladung traf diese drei Leitungen nicht direkt. Sie wirkte auf das ganze Gerät, und das konnte alle drei Leitungen gleichzeitig auf High ziehen. In diesem Moment las der MCU 111, einen völlig gültigen Code, und wechselte von selbst den Modus. Nach der Störung kehrten die Leitungen zu ihrem echten Wert zurück, aber der MCU war bereits im anderen Modus und blieb dort.
Nichts wurde beschädigt. Der Schutz hat seine Arbeit gemacht: kein Bauteil ist verbrannt, nichts hat sich verriegelt. Das Gerät hat einfach etwas getan, worum niemand es gebeten hatte.
![Animierte Grafik auf Englisch: Vor ESD geschützt, trotzdem getäuscht. Bild 1, Design mit zwei Prozessoren: U1 CPU (Linux / U-Boot) steuert drei Leitungen MODE2, MODE1, MODE0 zur U2 MCU, die MODE[2:0] liest. 01/06 Normalbetrieb: MODE[2:0] = 010, Modus 1; in diesem Design wählt Code 111 Modus 2. 02/06 ESD trifft das Gehäuse: die Entladung stört das ganze Gerät, ohne die drei Leitungen direkt zu berühren. 03/06 Alle drei Leitungen gehen auf High: aus 010 wird 111, die Störung drückt jede Leitung in dieselbe Richtung. 04/06 Die MCU liest einen gültigen Code: 111 = Wechsel in Modus 2, die MCU wechselt den Modus von selbst. 05/06 Die Leitungen erholen sich, der Modus bleibt falsch: Leitungen = 010, weiterhin Modus 2; Modus hat sich selbst geändert, Kriterium B nicht erfüllt. 06/06 Nach der Korrektur: Modus 2 = 101; 111 ist jetzt ein ungültiger Code und wird ignoriert; Leitungen, die sich gemeinsam bewegen, können nie 101 ergeben. Vorher: Modus 2 = 111, Störungen können ihn erzeugen. Nachher: Modus 2 = 101, für Störungen viel schwerer. smartatoms.com, from prototype to fleet.](https://smartatoms.com/wp-content/uploads/2026/11/P038-ESD-dual-brain-loop.gif)
Warum das durch die Prüfung fällt
IEC 61000-4-2 legt fest, wie die ESD-Prüfung durchgeführt wird: wo die Entladungen angesetzt werden, mit welchen Pegeln und wie oft. Was als bestanden gilt, entscheidet die Norm nicht. Das ist Aufgabe der Produktnorm, über die Bewertungskriterien.
Für ESD verlangt die Produktnorm meist Kriterium B. Das Gerät darf während der Entladung kurz stocken, muss aber bestimmungsgemäss weiterarbeiten, ohne Änderung des Betriebszustands. Ein Moduswechsel von selbst ist genau diese Änderung. Es spielt keine Rolle, dass jedes Bauteil überlebt hat und die Leitungen einen Moment später wieder stimmten. Das Gerät landete in einem Zustand, in dem es nicht sein sollte, und zwar ohne dass jemand es verlangt hätte.
Genau das macht diesen Fehler so ärgerlich. Der Schaltplan ist in Ordnung, der Schutz sitzt an seinem Platz und die Leiterplatte wirkt gesund. Die Schwachstelle ist die Bedeutung, die die Firmware einem Muster auf drei Pins gibt.
Die Lösung: ein gemischter Code
Die Lösung lag in der Firmware, nicht in der Hardware. Wir haben diesen Modus von 111 auf einen gemischten Code wie 101 verlegt.
Eine Störung, die auf das ganze Gerät wirkt, drückt tendenziell jede Leitung in dieselbe Richtung. Alles High und alles Low, 111 und 000, sind genau die Muster, die sie erzeugt. Ein gemischter Code wie 101 braucht eine Leitung, die in die andere Richtung geht, und entsteht deshalb viel seltener aus einer Störung, die alle Leitungen gemeinsam bewegt. Liegt der Modus auf 101, bedeutet das Muster «alles High» nichts mehr, und der MCU kann es als ungültig behandeln und ignorieren.
ESD-Fehler schliesst das nicht vollständig aus. Ein gemischter Code macht das gefährliche Muster deutlich unwahrscheinlicher, aber nicht unmöglich. Die Firmware braucht deshalb weiterhin Fehlererkennung und Fehlerbehandlung, um ungewollte Moduswechsel zu blockieren. Der neue Code ist die erste Verteidigungslinie, nicht die einzige.
Warum GPIO und nicht ein Standardbus wie I2C, UART oder SPI?
Eine berechtigte Frage. Manchmal sind ein paar GPIO-Leitungen die einzige praktikable Option:
- Der Modus wird aus U-Boot gesetzt, bevor die Treiber bereit sind.
- Zwischen den beiden Chips ist kein Bus mehr frei.
- Der MCU muss reagieren, auch wenn die CPU hängt.
Und ein Bus ist auch nicht immun. I2C, UART oder SPI können ebenfalls von ESD getroffen werden und brauchen deshalb auch Fehlererkennung. Die Wahl liegt nicht zwischen einer fragilen und einer sicheren Schnittstelle. Es geht darum, wo geprüft wird und wie viel Prüfung sich das System leisten kann.
| Schnittstelle | Wann sie passt | Was sie gegen ESD braucht |
|---|---|---|
| Einige GPIO-Leitungen | Modus wird aus U-Boot gesetzt, bevor die Treiber bereit sind, kein freier Bus, oder der MCU muss reagieren, auch wenn die CPU hängt | Keine sinnvolle Aktion auf 000 oder 111, stabiler Pegel über mehrere Lesevorgänge, ein Weg zurück in den Normalbetrieb |
| I2C, UART oder SPI mit Protokoll | Wenn die Ressourcen des MCU und die Randbedingungen des Systems es zulassen | Explizite Fehlererkennung (CRC oder Prüfsumme), Befehlsvalidierung und Bestätigung |
Was Sie in der Firmware prüfen sollten
Ob Ihr Design GPIO-Leitungen oder einen Bus nutzt: Für jeden Eingang, der das Verhalten des Geräts ändern kann, gelten dieselben vier Prüfungen:
- Bevorzugen Sie ein Protokoll mit expliziter Fehlererkennung. Eine CRC oder Prüfsumme, Befehlsvalidierung und Bestätigung, sofern die Ressourcen des MCU und die Randbedingungen des Systems es zulassen. Standardbusse wie I2C, UART oder SPI können ein solches Protokoll tragen.
- Wenn Sie GPIO-Leitungen nutzen, legen Sie keine sinnvolle Aktion auf 000 oder 111. Das sind die Codes, die eine Störung des ganzen Geräts erzeugt. Nutzen Sie gemischte Codes für echte Modi und behandeln Sie «alles High» und «alles Low» als ungültig.
- Bestätigen Sie einen kritischen Eingang, bevor Sie darauf reagieren. Achten Sie auf einen stabilen Pegel über mehrere Lesevorgänge. Ein echter Befehl ist beim nächsten Lesen noch da, eine Störung meist nicht.
- Geben Sie dem Gerät einen Weg zurück in den Normalbetrieb aus eigener Kraft, falls es trotzdem im falschen Zustand landet. Bei Kriterium B geht es um bestimmungsgemässen Betrieb ohne Zustandsänderung; ein Gerät, das sich selbst erholt, ist dem viel näher als eines, das auf einen Menschen wartet.
Nichts davon braucht ein neues Bauteil auf der Leiterplatte. Es ändert, was die Firmware zu glauben bereit ist.
Hardware und Firmware an einen Tisch
Der Schutz schützt die Pins. Die Firmware entscheidet, was ein Muster auf diesen Pins bedeutet. Werden beide getrennt entwickelt und treffen sich erst im Prüflabor, kann jede Seite für sich recht haben und das Produkt trotzdem durchfallen.
Der günstigste Moment, das abzufangen, ist vor dem ersten Pre-Scan. Listen Sie jeden Eingang und jede Schnittstelle auf, die den Betriebszustand des Geräts ändern kann, auch die unauffälligen zwischen zwei Chips auf derselben Leiterplatte, und stellen Sie für jede eine Frage: Kann eine Störung, die jede Leitung in dieselbe Richtung drückt, hier einen gültigen Befehl erzeugen?
Wie wir helfen
Bei Smart Atoms entwickeln wir Elektronik und Firmware gemeinsam, damit Leiterplatte und Code dieselbe Prüfung bestehen. Dazu gehören die Schnittstellen zwischen CPU und MCU in Dual-Brain-Designs, ESD- und EMV-Pre-Compliance und die Firmware-Regeln, die ein Gerät in seinem vorgesehenen Zustand halten. Sehen Sie, wie wir MCU-Firmware-Entwicklung angehen. Wenn Ihr Gerät ESD ohne Schaden überstanden hat und trotzdem durch die Prüfung gefallen ist, sprechen Sie mit einem Ingenieur.
Quelle: Smart Atoms, aus der ESD-Prüfung eines Dual-Brain-Designs (Linux-CPU und MCU); IEC 61000-4-2 und Bewertungskriterien der Produktnormen.
