Hard fault test

[Zanon.Luciano]

Posted on January 17, 2014 at 18:09

In order to test the Hard Fault interrupt, I modified the Systick example on ''STM32F0xx_Discovery_FW_V1.0.0'' as follows..

on main.c I added two lines: ------------------------------ int main(void) { uint8_t* BytePtr = (uint8_t)0x20002000;          *BytePtr = 0x5a;        //generate hardfault IRQ             /*!< ...........comment      */                /* Initialize Leds mounted on STM32F0-discovery */   STM_EVAL_LEDInit(LED3); -------------------------------------- on stm32f0xx_it.c I modified the error handler: ----------------------------------- void HardFault_Handler(void) {   TimingDelay_Decrement();    //really do nothing... } --------------------------------------- So, when the line       *BytePtr = 0x5a; is executed and the processor access the wrong location 0x20002000 a HardFault_Handler is called and executed. At return I expect the processor to execute the line   STM_EVAL_LEDInit(LED3); but instead it returns still at line ''*BytePtr = 0x5a;  and newly execute it, entering in loop!!! I am a novice on STM32  so it must be a stupid error but if I repeat the same test on the ''STM32F10x_vldiscovery_package'' it works as expected... Can someone help me?? Thanks, Luciano

[Tesla DeLorean]

Posted on January 17, 2014 at 21:50

Didn't you ask this same thing last week?

That it returns to the faulting instruction doesn't seem to be overly surprising behaviour, perhaps you need to go and adjust the return PC on the stack if you want it to advance. Generally speaking the failure is considered hard, so returning is a non-optimal solution. That it behaves differently between an M0 and M3 does surprise me a little. Are you sure your M3 example is actually faulting? A read in the 0x20200000 or 0x30000000 region might be more enlightening. Perhaps you should review Joseph Yiu's books on the topic, look at the TRM, and add some diagnostic output for the assorted core registers, and stacked context?

[Tesla DeLorean]

Posted on January 17, 2014 at 21:53

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Hard%20Fault%20test%20error&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=41

VLDiscovery [HardFaultException] R0 =00000000 R1 =0000005A R2 =80000000 R3 =0000000A R4 =08000D94 R5 =08000D94 R6 =20000000 R12 =00000008 LR =080008F1 PC =08000D02 <<< Instruction immediately following fault PSR =21000000 BFAR =E000ED38 CFSR =00000400 HFSR =40000000 DFSR =00000000 AFSR =00000000

[Tesla DeLorean]

Posted on January 17, 2014 at 23:28

A quick skim through the TRM, User Manual, and Yiu's Essential Cortex-M0, really doesn't call this out as a difference when transitioning from an M3/4 to an M0. Arguably it should, or the state be called out more explicitly/obviously.

I haven't tested the F0, as it doesn't have SWV and I haven't wired a USART on to it, but I'm going to assume your observation is valid. I think the general expectation is that Hard Fault handlers don't return. If you don't resolve the underlying error continued execution would seem to generate some what undefined behaviour as the following code presumably expects the preceding had executed and loaded registers correctly.

''Doc,'' says the patient, ''it hurts when I do this. What should I do?''

''Don't do that,'' says the physician.

[Zanon.Luciano]

Posted on January 18, 2014 at 12:12

yes but

no

satisfaction

...............

[Zanon.Luciano]

Posted on January 18, 2014 at 12:16

I used this

method

to test

the amount

of RAM

present in

a chip in order to

have a portable routine

,

this

works fine on

the M3

,

but

it does not work

on

m0

.

M3

processor loads

the PC

with address

following the

STRB

(which causes

hard

fault)

before entering the

IRQ

.

M0

processor

enters

IRQ

with the PC

still

pointing

instruction

STRB

(which causes

hard

fault)

,

and obviously this

causes the

loop.

Ok

, I have to

change my

routine

to avoid the problem

,

but

I think this is

a

conceptual error

in the microprocessor

, do you agree

?

[Tesla DeLorean]

Posted on January 18, 2014 at 16:00

I think this is

a

conceptual error

in the microprocessor

, do you agree? More likely a design decision to reduce the complexity of the logic. Does your fault handler recognize if it's your test code that traps, or do all Hard Fault just return?