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 12:18

Looks like you use an OS and tasks, which makes it a bit more difficult.

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

I understand this as 'crashes on some boards, runs fine on others'.

This might be a clue, but not necessarily. I expect all boards (MCU's ?) to be identical otherwise.

Seemingly 'random' crashes are often cause by resource overflow/corruption (mostly stack) due to external, asynchronous events (interrupts).

The path name of your images imply CoDeSys, which is  ... not quite small.

Besides of providing more about your hardware/software environment, I would first work backwards, and decode the hardfault reason from the SCB registers.

Try more than one hardfault event. Is the place and context the same, or does it change ?

Second step would be presumably an instrumentation of routines possible causing it.

[Diego Dell'Orto]

Posted on February 12, 2018 at 12:43

yes, the very strange is some board yes and some other not.

I've tried to replace the MCU and that board is now working properly, no more problems like before.

Some how I've the feeling it is the MCU having something, but honestly I'm not sure.

The place is not always the same, it looks that somehow there is a repetition of 5/6 different value of program counter, but...

Errors are NOCP, UNDEFINSTR, INVSTATE talking about Usage Fault, few times I get also Bus Fault PRECISERR.

Another strange things happening, is that if I place the PC to the value got by the hard fault handler, sometime the instruction is executed if I do that step by step, sometime that line is not executed, it looks the program stack there and no way to go further.

Where to see SCB register?

About interrupts, I was thinking about that, because a way to have more frequently the problem is to increase the amount of Tx/Rx interrupt fron CAN BUS interface. But again, very strange that on some board it happens quite easy and on some other board never.

Many Thanks and waiting further info.

[AvaTar]

Posted on February 12, 2018 at 13:00

The place is not always the same, it looks that somehow there is a repetition of 5/6 different value of program counter, but...

Errors are NOCP, UNDEFINSTR, INVSTATE talking about Usage Fault, few times I get also Bus Fault PRECISERR.

This is a typical symptom of a stack overflow, when 'odd' variables are interpreted as return addresses.

I would use a stack-check feature. Some toolchains have this option, and FreeRTOS too.

About interrupts, I was thinking about that, because a way to have more frequently the problem is to increase the amount of Tx/Rx interrupt fron CAN BUS interface.

This is another overflow symptom, because interrupts pound on the stack, too.

Though they (interrupts) are not the cause, they use to add a 'random' note, and complicate debugging.

Code instrumentation is good for synchronous problem (i.e. systematic bugs in the code), but not for stack overflows.

Where to see SCB register?

http://www.keil.com/appnotes/files/apnt209.pdf

 

[Tesla DeLorean]

Posted on February 12, 2018 at 12:47

Look at the code that's actually faulting. 

For chip/board specific issues and instability, look at voltages and capacitors on VCAP pins.

[Diego Dell'Orto]

Posted on February 12, 2018 at 12:53

We don't find the code that is faulting, because the PC is always different and it goes in place where code is normally working.

About hardware, could be a point. On one board only, the only one where we tried, by changing the MCU the problem looks solved. Maybe is not the microcontroller, but a soldering of a VCAP pin as you suggect.

I try to look.

Thanks

[AvaTar]

Posted on February 12, 2018 at 15:09

A correlation of hardfaults and individual MCUs is not very likely.

One exception that come to my mind - if your Flash interface (clock rates, wait states) settings are at the limit.

Your firmware might contain a race condition, wich could depend on hardware differences (like delays).

Like nested interrupts or specific error conditions in interrupts.

You can try to implement stub code for the other exceptions that escalate to hardfaults if unhandled.

Do you use the FPU, and the long stack frame (with FPU regs) ?