Enabling fault handlers

[LThal]

Hi.

I've run into an interesting situation and hopefully someone can give me an answer, or at least a suggestion.

We've got a product in development. In the last few months we've seen a couple of them (2 or 3, that we know of) freeze and become unresponsive. I'm assuming, for the moment, that some type of condition triggered a fault and the processor is hung in the Hard Fault handler (altho I'm aware there could be other reasons). The product is on a wireless network,

so if I can put together an error report I can transmit it on a watchdog reset.

I'm working with the STM32L152, running on FreeRTOS.

I've written expanded fault handlers for the Hard fault, the memory management fault, the bus fault and the Usage fault. Except for the Hard fault, the faults are not enabled on startup. I've tried enabling the other faults in several places, both in main() and in the startup task. Both of these generate errors, usually Hard faults. Here's the code I'm using to enable the faults:

shcsrStore = SCB->SHCSR;

shcsrStore |= (SCB_SHCSR_MEMFAULTACT + SCB_SHCSR_BUSFAULTACT + SCB_SHCSR_USGFAULTACT);

SCB->SHCSR = shcsrStore;

None of the error cases end up at any of the new fault handlers. Does anyone have any ideas? Thanks.

Lee

[waclawek.jan]

Check with a simple program - no RTOS, no interrupts.

Deliberately trigger e.g. a memory fault by accessing an unimplemented memory.

Read back and check the enable bits in SCB_SHCSR.

Check if the handlers' vectors are properly placed in the vector table, in disassembly. If you move the vector table and/or change VTOR, check that table too.

JW

[LThal]

Checking that I can enable the faults outside of my environment won't do much. I did check that the IVT is in the right place, and the fault handlers slots point to the actual code. There's no indication that the handlers are called, which is what I'd expect. I suspect the answer is more likely to be something related to FreeRTOS, but I don't have any proof of that yet.