STM32: HardFault simulieren

ich meinte den Hardfault-Handler. Wie kann ich den Prozessor dazu 
bringen, daß er mir diesen anspringt.

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.

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.

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.