Hallo, wie kann ich einen Hardfault per Software simulieren (auslösen)? Ich möchte prüfen, ob die in der Hardware Fault-Routine stehende Funktion geht. Gruß Martin
:
Bearbeitet durch User
Martin M. schrieb: > wie kann ich einen Hardware Fault per Software simulieren (auslösen)? Indem Du sie aufrufst oder Deine Hardware entsprechend veränderst, so daß Dein Programm sie als fehlerhaft erkennt. Oder meinst Du etwas komplett anderes, nämlich den Hardfault mit seinem Hardfault-Handler? Der hat aber nichts mit einem Hardwarefault zu tun.
ich meinte den Hardfault-Handler. Wie kann ich den Prozessor dazu bringen, daß er mir diesen anspringt.
Martin M. schrieb: > ich meinte den Hardfault-Handler. Wie kann ich den Prozessor dazu > bringen, daß er mir diesen anspringt. Du kannst z.B. Speicher adressieren, den es gar nicht gibt.
Mal abgesehn von der zweifelhaften Praxis soetwas direkt auf der Hardware zu testen lässt sich der Hardfault-Handler aufrufen wie jede andere Funktion auch.
Speicher adressieren, den es gar nicht gibt geht nicht. Scheint der Compiler zu korrigieren. Ebenso Division durch Null bringt ihn nicht zum Absturz. Grund für die Frage: Es besteht der Verdacht, daß ein HardwareFault kommt. Um zu testen, ob das tatsächlich das Problem ist, soll eine gewisse Prozedur im Hard-Fault-Handler vollzogen werden. Man will nun testen, ob das auch so funktioniert wie gewünscht, oder ob irgend etwas davon in diesem Zustand nicht geht.
Vincent H. schrieb: > lässt sich der Hardfault-Handler aufrufen wie jede > andere Funktion auch. Vielleicht hat er Code im Handler stehen der die Adresse und den Typ des Faults und den Stack beim Eintreten des Faults extrahieren soll, da nutzt es ihm wenig wenn er die Funktion einfach normal aufruft. Er will einen echten Hardfault provozieren um zu sehen ob es das macht was es soll.
Martin M. schrieb: > Speicher adressieren, den es gar nicht gibt geht nicht. > Scheint der Compiler zu korrigieren.
1 | *(volatile uint32_t*)0x12345678 = 0x8765432; |
funktioniert nicht? Schau ins Disassembly!
> Ebenso Division durch Null bringt ihn nicht zum Absturz.
Division durch Null führt nur bei Integer zu einem Absturz, bei
Floating-Point gibt es ein (un)normales Ergebnis. Auch hier: Schau ins
Disassembly!
Allgemein: Überprüfe deine Annahmen. Bringt ja nix, wenn der Prozessor
seinen HardFault aufruft, scheitert, neu startet und dein Debugger so
tut als wäre nichts gewesen.
:
Bearbeitet durch User
1 | void breakpoint (void) |
2 | {
|
3 | // verhaelt sich je nach Debugger-Status unterschiedlich
|
4 | __asm__ (" bkpt"); |
5 | }
|
6 | |
7 | void undefined (void) |
8 | {
|
9 | // es gibt auch andere, offizielle undefined opcodes
|
10 | __asm__ (" .word 0xffffffff"); |
11 | }
|
12 | |
13 | void vector_table_crash (void) |
14 | {
|
15 | SCB->VTOR = 0xffffffff; |
16 | }
|
17 | |
18 | void MPU_test_null_pointer (void) |
19 | {
|
20 | // crash, wenn 0x0 bis 0xirgendwas per MPU nicht gemappt ist und
|
21 | // fuer den MemManage fault der hard fault handler eingetragen ist
|
22 | printf ("%lx\n", * (uint32_t *)4); |
23 | }
|
24 | |
25 | int recursion (int moe) |
26 | {
|
27 | recursion (moe + 1); |
28 | return moe; |
29 | }
|
Also wenn du keinen undefined Handler registriert hast (also alles auf den hardfault rauskommt), dann: asm ("udf #0"); oder asm("udf"); Das ist eine definierte undefined Instruction ;) div0 geht auch, aber den div0 Trap muss man im SCB ersteinmal aktivieren. (was sich empfiehlt) Vincent H. schrieb: > Mal abgesehn von der zweifelhaften Praxis soetwas direkt auf der > Hardware zu testen lässt sich der Hardfault-Handler aufrufen wie jede > andere Funktion auch. Unsinniges Geschwätz! Er will ja grade gucken ob er die HW Register richtig ausließt, welche bei einem Fault vom ARM core gesetzt werden.
Simulieren ist zu ungenau. Nur echte Tests geben relevante Aussagen. Anleitung siehe Bild.
Auf eine ungrade Adresse einen Schreib- oder Lesezugriff in Wortbreite machen. Im Zweifelsfall halt ein paar Zeilen Assembler nehmen.
Es wurde ja vieles dargestellt. Da sollte genug für die Umsetzung dabei sein. Nur ein paar zusätzliche Hinweise, warum es evtl. bisher nicht geklappt hat. Je nach STM32 Typ gibt es leicht unterschiedliche Verhaltensweise. Das Core Handbuch hilft im Zweifelsfall. Die Adressen sind teilweise gespiegelt. U.a. ist ab Adresse 0 gültiger Speicher. Die "ungültige Adresse" muss schon sinnvoll gewählt werden. TheBug schrieb: > Auf eine ungrade Adresse einen Schreib- oder Lesezugriff in Wortbreite > machen. Kommt auf den Typ an, ob unaligned Zugriffe gehen oder nicht.
Steffen R. schrieb: > TheBug schrieb: >> Auf eine ungrade Adresse einen Schreib- oder Lesezugriff in Wortbreite >> machen. > > Kommt auf den Typ an, ob unaligned Zugriffe gehen oder nicht. Bei M3, M4 und M7 muss man den unaligned Trap auch erstmal im SCB aktivieren. Sonst ist das erlaubt. Code lesen von einer graden Adresse (weil bei Thumb Bit 0 immer gesetzt ist) dürfte einen Hardfault ziemlich sicher auslösen. Was jetzt auch nur für Cortex-M gilt.
TheBug schrieb: > Auf eine ungrade Adresse einen Schreib- oder Lesezugriff in Wortbreite > machen. Im Zweifelsfall halt ein paar Zeilen Assembler nehmen. Funktioner bei ArmV7-M (Cortex-M3 und aufwärts) per default nicht. Witzigerweise wird beim 64-Bittigen Zugriffen (also unt64_t*) gerne mal die LDRD/STRD Tnstruktion verwendet, und die erzeugt wiederum Unaligned Faults. Auf den Cortex-M4F könnte man unaligned Faults via FPU erzeugen, die möchte ihre Daten AFAIK auch word-aligned lesen.
Bitte 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.