STM32F427 NOCP UNDEFINSTR hard fault problem

[Diego Dell'Orto]

Posted on February 12, 2018 at 11:52

Hello,

I need help, because we are facing hard fault with the STM32F427 MCU.

Same software over some MCUs works perfectly, over someother crash and we are not able to understand the reasons.

Attached screen shot of debugging sections.

Any Idea?

Many Thanks,

Diego

#hard-fault #undefinstr #nocp #stm32f427

[AvaTar]

Posted on February 12, 2018 at 16:09

I still suspect a stack overflow, in particular the processor stack (NOT the RTOS task stacks).

This size is 'hidden' in the uVision project settings.

Doesn't uVision have a stack check feature ?

This consists usually in an initialisation of the stack with a specific pattern.

If you can't see this pattern anymore when hardfaulting, the stack is too small.

I've already tryied to slow down from 180Mhz to 120Mhz, but the behaviour is the same.

Not surprising ...

How long does it take for a board to end up in a hardfault ?

Does it hardfault with all external stimulations (communications, dig. inputs) detached ?

Have I to do like following for the hard fault handler for the othr faults?

The 'fault report' window in your images already contain the relevant SCB register content.

IMHO no great need to improve the fault handlers for that purpose.

[Tesla DeLorean]

Posted on February 12, 2018 at 17:06

Ok, but you keep posting screen shots not showing the registers at the hard fault. I don't see content of stacked_*** variable, nor the stack memory. You need to dig backward, not just die at DebugBreak();

If you have console output working, consider dumping registers

 

Have routines checking your own stack depth usage. Make sure local/auto variables are cleared properly also, as will contain random junk.

[Diego Dell'Orto]

Posted on February 12, 2018 at 17:27

stacked_r0 = 0x00000000

stacked_r1 = 0x027B0812

stacked_r2 = 0x1000DC5A

stacked_r3 = 0x00000000

stacked_r12 = 0x0804503B

stacked_lr = 0x08100FA0

stacked_pc = 0x027D0812

stacked_psr = 0x81000000

most of the time the stacked value are different one time from the following.

if I look ''lr'' is randmly different.

flash area is from 0x08008000 to 0x081FFFFF

I still have to do the hardware investigation.

Thanks

[Diego Dell'Orto]

Posted on February 12, 2018 at 17:29

Stack_Size      EQU     0x00000400

                AREA    STACK, NOINIT, READWRITE, ALIGN=3

Stack_Mem       SPACE   Stack_Size__initial_sp; <h> Heap Configuration;   <o>  Heap Size (in Bytes) <0x0-0xFFFFFFFF:8>; </h>

Heap_Size       EQU     0x000D000

                AREA    HEAP, NOINIT, READWRITE, ALIGN=3

__heap_baseHeap_Mem        SPACE   Heap_Size__heap_limit

for further info

[AvaTar]

Posted on February 12, 2018 at 18:18

most of the time the stacked value are different one time from the following.

if I look 'lr' is randmly different.

With a stack overflow involving interrupts, this would be expected.

[Diego Dell'Orto]

Posted on February 14, 2018 at 12:19

we are doing some hardware investigation as Cliv One suggested.

I'll check forward about stack overflow

Thnaks for now and let see