Hallo zusammen, ich habe in einer EMV Schulungsunterlage gelesen das es sinnvoll sei unbelegten Speicher des µC mit Restart-Kommandos zu belegen. Das finde ich eine sehr gute Idee, nur frage ich mich wie ich das umsetzen sollte. Hintergrund ist ja, falls ich einen unerlaubten Sprung mache und der program counter an eine Flash Speicheradresse springt die im unbeschriebenen Speicherberich liegt, dann müsste dort statt den üblichen 0xFFFFFFFF halt ein Resetvector stehen der auf meine Start-Adresse zeigt. Eigentlich wird in diesem Fall immer ein Trap ausgelöst und dort kann ich das dann auch behandeln, aber im Prinzip soll man ja alles tun was der Sicherheit und vor allem der Zuverlässigkeit dient, oder wie seht ihr das? Viele Grüße
Bene R. schrieb: > oder wie seht ihr das? Deutlich mehr als 99,999% der Geräte brauchen und machen das nicht.
Das hängt stark vom Prozessor ab. Das grundlegende Problem ist der illegale Sprung selbst, geht am einfachsten durch einen unaufgeräumten Stack - dann geht der ret oder reti in's Nirvana. Aber das ist der eigentliche Fehler, den man beheben müsste, alles andere sind nur Krücken. Wenn ich diese Anforderung hätte, würde ich eine NOP-Rutsche verwenden (wie Malware). Also Füllen mit irgend einem Befehl, der nur eine einzige Speicheradresse belegt und ganz am Ende ein Sprung. Egal wo dieses Feld getroffen wird, läuft der Prozessor dann durch alle NOPs und führt am Ende den Sprung/Reset aus. Nachtrag: Schützt mich aber nicht vor dem Problem ansich. Umso größer das Programm, desto höher die Chance, daß beim fehlerhaften Sprung beliebiger Programmcode getroffen wird und dann bin ich vor nichts mehr sicher, auch nicht vor Hardwareschäden im ungünstigsten Fall.
:
Bearbeitet durch User
Ben B. schrieb: > und ganz am Ende ein Sprung. Ich würde versuchen am Ende einen echten Reset durchzuführen. Ein Jump auf Adresse 0x0000 (oder wohin auch immer) startet das Programm zwar "neu", initialisiert jedoch nicht die Hardware-Register auf default. Entweder der µC hat einen dezidierten Reset-Befehl oder man initialisiert in den letzten Befehlen im Speicher den Watchdog und löst per Endlosschleife einen Watchdog-Reset aus. Ist zwar etwas fummelig, aber die "sichersten" Lösungen. Alternativ kann (und sollte man auch tunlichst) den Watchdog schon im Hauptprogramm initialisieren und im ungenutzten Speicher einfach nur eine Endlosschleife setzten. Gruß
> Deutlich mehr als 99,999% der Geräte brauchen und machen das nicht.
Kommt drauf an. Wenn du Pruefschaerfegrad A gewohnt bist ist das
natuerlich
quatsch. Bei Consumerzeugs aber vielleicht hilfreich mit grenzwertiger
Hardware doch durch die EMV zu kommen.
Olaf
Bene R. schrieb: > falls ich einen unerlaubten Sprung mache und der > program counter an eine Flash Speicheradresse springt die im > unbeschriebenen Speicherberich liegt, dann müsste dort statt den > üblichen 0xFFFFFFFF halt ein Resetvector stehen der auf meine > Start-Adresse zeigt. Bei einem AVR: Angenommen, kein Bootloader, dann.... 0xFFFF entspricht einem NOP Ein Sprung in einen unbelegten Bereich führt ao zwangsläufig auf die NOP Rutsche. Die rasselt durch bis zum Wraparound des ProgrammConters. Der nächste "Befehl" ist der Resetvector Also beim AVR: Alles schon fertig.
Bene R. schrieb: > unbelegten Speicher des µC mit Restart-Kommandos zu belegen. Wenn die MCU im unbelegten Speicher versucht Befehle auszuführen hat man bereits größere Probleme. Das ist Gebrabbel von einem der EMI kann aber MCUs nur halb verstanden hat. Ignorier das einfach olaf schrieb: > Bei Consumerzeugs aber vielleicht hilfreich mit grenzwertiger > Hardware doch durch die EMV zu kommen. Quatsch. Das senkt doch nicht EMI Emmisionen. Das soll bei heftigen Ereignissen die die MCU völlig aus dem Tritt gebracht haben dafür sorgen das die einen Reset hinlegt. Die Idee alleine ist aber schon nicht zuende gedacht. Wenn ich fröhlich pfeifend abwarte bis eine amokende MCU sich quer durch ihren Speicher gefressen hat und in Bereichen Code ausführt, in dem kein Code liegt, sonder nix oder Daten, tut die eben alles mögliche das vollkommen unvorhersehbar ist. Ob die jemals da ankomt wo die reset Anweisungen liegen, ist völlig offen. Dafür wurden Watchdogs erfunden. Kommt die MCU nicht alle X ms wieder in ihrer Main Loop an und setzt den zurück, führt der WDT einen Reset durch.
Ben B. schrieb: > Egal wo dieses Feld > getroffen wird, läuft der Prozessor dann durch alle NOPs und führt am > Ende den Sprung/Reset aus. Wenn schon sowas, würde ich am Ende eher einen Endlosloop einbauen und dort abwerten bis der WD zuschlägt. Dort dann auswerten was zu dem Ereignis geführt hat... Ein Sprung zu einer bestimmten Adresse am Anfang ist eben kein echter Reset. Die Hardware bekommt davon ja nichts mit und befindet sich in irgendeinem Zustand. Der Programmanfang müsste also damit rechen das sich alles (nicht nur die verwendete Hardware) in irgendeinem beliebigen Zustand befindet und nicht nur wie normalerweise in den durch einen Reset definierten Zustand. Und wenn man annimmt das so heftige Störungen aufgetreten sind, dass der PC fehlerhaft ist, dann sind alle möglichen Register genauso fraglich.
Bene R. schrieb: > Hintergrund ist ja, falls ich einen unerlaubten Sprung mache und der > program counter an eine Flash Speicheradresse springt die im > unbeschriebenen Speicherberich liegt, dann müsste dort statt den > üblichen 0xFFFFFFFF halt ein Resetvector stehen der auf meine > Start-Adresse zeigt. Hallo Bene. Ein Reset-"Vektor" hilft dir da nix. Du müsstest da schon einen Sprung zum Reset reinschreiben. Ben B. schrieb: > Wenn ich diese Anforderung hätte, würde ich eine NOP-Rutsche verwenden > (wie Malware). Also Füllen mit irgend einem Befehl, der nur eine einzige > Speicheradresse belegt und ganz am Ende ein Sprung. Egal wo dieses Feld > getroffen wird, läuft der Prozessor dann durch alle NOPs und führt am > Ende den Sprung/Reset aus. Die Lösung würde ich da näherliegender erachten. Am Besten wäre es jedoch tatsächlich, das über andere Mechanismen abzufangen und dann auch zu analysieren warum das so passiert ist. Vielleicht also zur Runtime Zyklenzeitauswertung oder Tracepoints mitschreiben und dann beim Auflauf auf die NOP-Rutsch nicht am Ende ohne Bedingungen einen Reset ausführen sondern die Informationen über das WOHER sichern, damit der Fehler gefunden werden kann. rgds
6a66 schrieb: > die Informationen über das WOHER sichern, damit der Fehler gefunden > werden kann. Diese Informationen bringen nichts. Man weiß in dem hier beschriebenen Fall sowieso, woher der Fehler kommt: er kommt von der untauglichen Hardware, die auf elektromagnetische Störungen empfindlich reagiert und dadurch den Programmzähler oder den Stack verbiegt. Das ist nicht der Fall, wenn die Software einfach nur unverhoffte Eingangsimpulse bekommt. Dann macht sie halt Blödsinn, den aber durchaus kontrolliert. Wobei es da natürlich schon auch solche Spezialisten gibt, die sich den Stack von Pin-Interrupts überlaufen lassen. Aber das gehört dann eindeutig in die Liga "Anfängerfehler".
:
Bearbeitet durch Moderator
Lothar M. schrieb: > er kommt von der untauglichen Hardware, die auf > elektromagnetische Störungen empfindlich reagiert und dadurch den > Programmzähler oder den Stack verbiegt. Ich hab mal bei MC eine Schulung über direkt gesteuerte Schaltnetzteile mitgemacht. Der Vortragende war definitiv voll im Saft bei dem Thema und meinte das bei den Leistungen / Feldern ein gelegentliches Amoken des dsPic nicht auszuschliessen wäre. Da die Abstürze bei den Schaltflanken passieren muss der WDT reset + reboot so schnell kommen, das in der Zeit weder die Halbleiter die Grätsche gemacht haben, noch die geregelte Spannung das zulässige Fenster verlassen hat. Das fand ich einigermaßen beeindruckend...
Mal abgesehen vom Sinn. Oft kann ich den Linker nur anweisen unbenutzte Bereiche mit einem Byte zu füllen. Bei einem 8085 wäre das ja latschi, da gibt es die RST-Befehle, die in einem Byte einen definierten Sprung ausführen. Die Nop-Rutsche wurde ja auch schon erwähnt. Wie aber bringe ich den Compiler/Linker dazu, vor jeden normalen Code die PC-Fehler-Behandlung zu setzen ? Eine sehr schräge Lösung wäre, wenn der Opcode für den Sprung z.B. 0x02 ist, alles mit diesem Wert zu füllen und auf Adresse 0x0202 den irregelaufenen PC einzufangen versuchen. Ein hoch schonmal auf aktuelle Mikrocontroller, die beim Zugriff auf ein Loch im Adressbereich einen Trap auslösen, dass wäre ja sonst gar nicht abzufangen. Wobei ich mir nicht sicher bin, ob die auch ein Ausführen der SFR Inhalte als Code abblocken.
Max M. schrieb: > Ich hab mal bei MC eine Schulung über direkt gesteuerte Schaltnetzteile > mitgemacht. > Der Vortragende war definitiv voll im Saft bei dem Thema und meinte das > bei den Leistungen / Feldern ein gelegentliches Amoken des dsPic nicht > auszuschliessen wäre. Das sind dann auch die 0,001%, wo sowas sinnvoll ist oder sein könnte. Allerdings läuft dann der µC mit sehr hoher Wahrscheinlichkeit nicht in den unbenutzten Bereich und springt von dort aus zurück, sondern ein Hardwarewatchdog erkennt, dass die nächste Schaltflanke fehlt, schaltet die Leistungschalter ab und setzt den µC zurück. Der muss dann eben nach ein paar µs wieder mit Vollgas an der Arbeit sein. Und das ist kein Problem, weil der Oszillator ja mit Vollgas durchläuft. Der eigentliche Witz an dem Design ist also der Watchdog.
Lothar M. schrieb: > Hardwarewatchdog Geht nur damit und das mit sehr engem Timing. Ich habe auch noch niemals vorher gehört das man freien Speicher mit Reset Anweisungen fluten soll. Von EMV gerechter SW faselte mal ein Prüfer und meinte da irgendwie nebulös sich gegen bitkipper zu härten, aber das hakt man unter 'Geräusch' ab. Jede ernsthafte MCU Software die ein Mindestmaß robust sein muss nutzt geeignete Maßnahmen und das ist bestimmt nicht freien Speicher mit reset Anweisungen zu füllen.
So etwas habe ich noch nie gemacht. Wenn die CPU da irgendwie rein läuft, dann resettet sich das meist von selber. Was ich aufgesetzt habe ist der Watchdog. Falls die CPU 5 Sekunden irgendwo hängt, dann wird ein Reset ausgelöst. Das finde ich sinnvoller.
Na was Leistungsbauteile angeht, steht ja der Schutz dieser im Vordergrund. Ich würde da irgend einen hardwarebasierten Schutz einbauen, der beim Überschreiten irgendwelcher Limits alle Leistungshalbleiter in einen sicheren Zustand bringt und evtl. sowas wie eine Freigabe löscht. Dann kann sich der gecrashte µC in Ruhe neu starten, er könnte auch ein Reset von der Schutzschaltung bekommen und darf dann ganz von vorne anfangen... Schauen was Sache ist, Freigabe neu setzen, Leistungshalbleiter ansteuern.
> Das senkt doch nicht EMI Emmisionen.
Du hast leider nur die haelfte von EMV verstanden.
Olaf
olaf schrieb: >> Das senkt doch nicht EMI Emmisionen. > > Du hast leider nur die haelfte von EMV verstanden. Na dann großer Meister erleuchte uns und erkläre doch bitte inwiefern ein reset Befehl in einem Speicher, der im Normalfall nicht benutzt wird das EMV Verhalten verbessert. Denn DAS ist es worum es in dem Thread geht.
Ihm geht es darum, das eigene Gerät gegen fremde Störstrahlung zu härten.
> Na dann großer Meister erleuchte uns Bitte: https://www.demvt.de/publish/viewfull.cfm?objectid=ba9bb5ca%5Fe081%5F515d%5F7417d96d5ea45dae Kriterium C: Eine Funktion des Prüfobjekts wird während der Prüfbeanspruchung nicht bestimmungsgemäß ausgeführt. Nach Wegnahme der Prüfbeanspruchung arbeitet das Prüfobjekt jedoch wieder einwandfrei. Du erhoehst damit in diesem Fall die Wahrscheinlichkeit das dein Geraet den Arsch wieder hoch bekommt und bestehst den Test. Kriterium A: Alle Funktionen des Prüfobjekts arbeiten während und nach der Prüfung bestimmungsgemäß. Das heisst, die Einwirkung der Prüfstörgröße auf das Prüfobjekt hat keinen Einfluss auf dessen Funkionalität. In diesem Falle nuetz es nix. Das Gaeraet bootet neu und du bist durchgefallen. EMV ist nicht nur Abstrahlung sondern auch Einstrahlung. Olaf
Das ist doch Schwachsinn. Wieso sollte ausgerechnet die Rücksprungadresse im Stack oder auch direkt der Programmcounter einen Bitfehler bekommen? Unter der Bedingung, daß es zu einem Bitfehler im R/W-Speicher kommt, ist doch angesichts der Speichergrößen die Wahrscheinlichkeit überwältigend, daß irgendeine andere Speicherstelle manipuliert wird. Sprich, jede Variable könnte betroffen sein. Das Programm läuft dann weiter, aber unkontrolliert, da mit willkürlich geänderten Variablen. Wenn man sowas handhaben will, dann nimmt man mindestens drei Geräte und macht ein Voting. Das Gerät, das abweicht, bekommt einen Reset verpaßt.
Es ist auch immer die Frage, wogegen man das Gerät härten möchte. Es wird ziemlich schwierig, z.B. einen Plattenspieler zu bauen, der selbst unter kräftiger Vorschlaghammer-Einwirkung noch ohne Aussetzer funktioniert.
Nop schrieb: > daß irgendeine andere Speicherstelle manipuliert wird. > Sprich, jede Variable könnte betroffen sein. Wenn du einen uC nimmst, der sein Programm aus einem RAM ausführt (z.B. die GigaDevice STM32 Nachbauten), dann kann genauso "leicht" der Programmcode betroffen sein. olaf schrieb: > EMV ist nicht nur Abstrahlung sondern auch Einstrahlung. Es geht hier im Thread vorrangig um diese Suszeptibilität, um die Empfindlichkeit gegen Störeinkopplung.
olaf schrieb: > Du erhoehst damit in diesem Fall die Wahrscheinlichkeit > das dein Geraet den Arsch wieder hoch bekommt und bestehst > den Test. Wahrscheinlichkeit.... Also wenn das Fehlerbild nett genug ist und die richtigen Bits kippen lässt, die MCU tatsächlich auf den Befehlsadresse und nicht knapp daneben springt, bestehe ich, ansonsten nicht? Na da lasse ich den unbenutzten Speicher doch wie er ist, setze auf den WDT und habe 100%tige Sicherheit das mein Gerät jeden Fehler übersteht der nicht zu HW Defekten führt.
Vielen Dank für eure vielen Antworten! Zusammenfassend kann man sagen, dass eine ordenliche Trap-Behandlung zusammen mit einem activierten Watchdog eine absolut ausreichende Absicherung darstellen. Natürlich kommt es immer auf den Anwendungsfall an und ich habe auch schon an Projekten gearbeitet da musste der WDT z.B. ein externer Baustein sein und mit einem einfachen rücksetzten des WDT war es auch nicht getan sondern es musste immer eine Rechenaufgabe korrekt beantwortet werden um auch gaaanz sicher zu sein das der Kern und die ALU noch intakt sind, für meine Zwecke habe ich aber ein gutes Bild aus euren Antworten bekommen und möchte mich nochmals bedanken!
FOp schrieb: > Ein hoch schonmal auf aktuelle Mikrocontroller, die beim Zugriff auf ein > Loch im Adressbereich einen Trap auslösen Das mag vielleicht gehen, bei MCs, die Lücken im Adreßbereich haben, in denen kein Flash implementiert ist. Aber Flash, der 0xFFFF enthält, können sie auch nicht von Code unterscheiden. Und bei MCs nach Harward ist der Flash typisch in den gesamten Adreßbereich gespiegelt, d.h. jede Adresse ist gültig. Gegen EMV helfen aber keine Softwaretricks und auch kein Watchdog. Ein EM-Puls kann den MC dauerhaft blockieren lassen oder auch Flash-Pages löschen. Ich hatte mal den Fall, daß nach einem Überschlag selbst am Resetpin der MC sich nicht mehr aufwecken ließ. Es half einzig das Redesign der Platine, d.h. Aufteilen der Planes, so daß hohe Spannungs- und Strompulse nicht mehr unter dem MC lang flossen, sondern räumlich getrennt davon. Ich verwende daher immer Split Planes, die nur an definierten Punkten per Net-Tie verbunden sind.
Bene R. schrieb: > Zusammenfassend kann man sagen, dass eine ordenliche Trap-Behandlung > zusammen mit einem activierten Watchdog eine absolut ausreichende > Absicherung darstellen. Selbsttäuschung ja, Absicherung definitiv nein. Der Watchdog hilft ausschließlich und begrenzt gegen Softwarefehler. Der Softwarefehler muß stochastisch genug sein, daß er nach einem Watchdogreset nicht immer wieder erneut auftritt.
:
Bearbeitet durch User
Es gibt ESD Piezo Prüfpistolen günstig zu kaufen, die lassen recht gut eine quantitative Beurteilung von Maßnahmen zu. Z.B. habe ich gemerkt, daß der Quarz am MC sehr empfindlich ist. Mit einem Quarzoszillator arbeitet der MC deutlich störfester. Mit der Pistole habe ich auch festgestellt, daß der Watchdog nur wenig nützt. Ich habe ein einfaches Blinkprogramm gestartet. Mal stand das Blinken durch den ESD-Puls und berappelte sich nach 2s wieder (Watchdogtimeout). Oft blieb es aber permanent stehen bis zum Power-Off und low ziehen am Resetinput brachte auch nichts. Ein externer Watchdog müßte also kurz mal die VCC abschalten.
Peter D. schrieb: > Es gibt ESD Piezo Prüfpistolen günstig zu kaufen, die lassen recht gut > eine quantitative Beurteilung von Maßnahmen zu. Eine qualitiative Bewertung lässt sich mit einem Viehtreiber für 20€ machen. Den Aufbau habe ich im Beitrag "Re: Tiefentladungsschutz mit Attiny und P-Kanal Fet" bechrieben. Er ähnelt nicht zufällig dem Setup beim Burst-Test. > Z.B. habe ich gemerkt, daß der Quarz am MC sehr empfindlich ist. Mit > einem Quarzoszillator arbeitet der MC deutlich störfester. Allerdings muss man da aufpassen, dass der mit seinen steilen Flanken nicht zum Störsender wird. Die Abhilfe sind dann Oszillatoren mit Trapez (clipped sinewave) oder echtem Sinus am Ausgang. https://abracon.com/parametric/oscillators?mounting_type=Surface%20Mount&output=Clipped%20Sine%20Wave
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.