HardFault auf Cortex-Mx

[Progger (Gast)]

In einem Artikel

http://embeddedgurus.com/state-space/2011/09/whats-the-state-of-your-cortex/#comments

habe ich den Vorschlag gelesen, den Stack auf einem Cortex-M an den 
Anfang des RAMs zu legen.

Begründung war u.a. dass dadurch bei einem Stack Overflow eine HardFault 
Exception erzeugt wird, da dann push/pop auf einen nicht genutzten 
Adressbereich also Busfehler -> HardFault.

Beim ersten mal lesen erschien mir dies auch sehr plausibel. Je länger 
ich aber darüber nachdenke, desto komischer kommt mir das vor:

Angenommen ich rufe eine Funktion in C auf, welche via "push" den 
Kontext sichert, was nun zu einem Stack Overflow und einem Busfehler 
führt. Jetzt würde doch die HardFault Exception erzeugt, welche 
automatisch den Stack-Frame sichern möchte. Dies funktioniert nun aber 
ebenso wenig. Ich kann nun nirgends etwas zu dem dann auftretenden 
Verhalten finden (eine HardFault Loop? trotzdem Sprung in die Hard Fault 
ISR?) und die Frage ist deshalb: Was passiert dann?


PS: Sofern es einen Unterschied macht, ich Frage für einen Cortex-M0+.

[Progger (Gast)]

Okay, in "The definitive Guide to the ARM Cortex M0" steht die Antwort:

"If a bus error response occurs at exception, entrance (stacking) does 
not cause a lockup, even if is entering hard fault or entering NMI 
exception."

[Jim M. (turboj)]

Tritt ein Fehler (Fault) beim Stacking auf, wird der Hardfault Handler 
ohne weiters Stacking ausgeführt. Es gibt ein Bit (STKERR im BFSR 
Register) das dies anzeigt.

Tritt ein Fault während der Ausführung des Hardfault Handlers auf, geht 
der Core in den Lockup.

Der Cortex M0 Kern ist unter http://infocenter.arm.com dokumentiert, 
falls der Hersteller keine eigne Doku anbietet.

[Progger (Gast)]

Jim Meba schrieb:
> Es gibt ein Bit (STKERR im BFSR
> Register) das dies anzeigt.

Not on Cortex-M0+ unfortunately. Aber Prüfung ob SP noch in den Grenzen 
liegt reicht ja