Hard Fault on stm32 in prvPortStartFirstTask

Kernel
1

Hello,

I use a bootloader to flash and boot the Freertos application on stm32h753. On power up, I get a hard fault in prvPortStartFirstTask and the PC points to the instruction " cpsie f". However on watchdog reset and reboot, it continues without an error. What could be causing a hard fault on enabling global interrupts with cpsie i in prvPortStartFirstTask on first boot?
Here are some of the other register values.
stacked_r1 = f00000
stacked_r2 = e000ef34
stacked_r3 = c0000018
stacked_r12 = a
stacked_lr = 80250b1
stacked_pc = 8024db8
stacked_psr = 29000000
_CFSR = 400
_HFSR = 0
_DFSR = 0
_AFSR = 0
_BFAR = 0

_MMAR = 0

2

Looking here, this seems to indicate IMPRECISERR. Can you try to follow the instructions on this page to debug imprecise faults - Debugging and diagnosing hard faults on ARM Cortex-M CPUs

1 Like
3

Thank you, i will check and revert

4

I’ve had that kind of thing happen. The value of the PC register may tell you where the fault is. Generally, the kind of fault that happens immediately at startup can be laid to memory locations being accessed that are NOT supposed to be accessed. An example would be mapping a non-working (non initialized) memory region into processor space and locating a variable (initialized) there.

Another possibility is a pointer that is pointing to an area outside the processor’s permitted address space (there are a few), causing an access to a protected area.

I’d start debugging and single step through the program. It might help.

1 Like
5

Thanks for your inputs. I will try and revert.

6

Here is an update. I had tried making the imprecise fault to precise by disabling write buffering b setting the DISDEFWBUF bit in ACtlr reg. However, on reading back- the bit was still clear. This is STM32H753 . Also , the CFSR value was the same. I tried few changes to narrow down the issue. Found that I had disabled I/D cache due to some issue with UART console prints. On re-enabling I/D cache, the issue is not seen so far.

The issue used to happen earlier only first time after power up .

7

I’m not sure why enabling a cache would fix your issue. Caches are for performance improvement and so, their presence or absence should impact only performance. You may be masking the real problem here. Is it possible for you to share code?

8

I’ll try to share some code. This is a custom board and uses a bootloader .