Adding Fault Handlers to application

Kernel
1

lee-t56 wrote on Thursday, August 08, 2019:

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

2

rtel wrote on Thursday, August 08, 2019:

Not sure this is a FreeRTOS question as such unless the start scheduler function in the FreeRTOS port.c file for the port you are using is reprogramming these registers, which I don’t think it is but can’t check right now.

Just in case suggest testing this by enabling the faults in main(), then attempting to deliberately generate one of these faults also in main() before the scheduler is started to see if the handler is hit. If it is, then do the same from a task after the scheduler is started to see if the behavior is different. If so then we can assume the scheduler is having an influence on the behavior.

3

aggarg-aws wrote on Thursday, August 08, 2019:

You are probaly using the wrong defines there. The code should look like the following:

SCB->SHCSR |= ( SCB_SHCSR_MEMFAULTENA | SCB_SHCSR_BUSFAULTENA | SCB_SHCSR_USGFAULTENA );
4

lee-t56 wrote on Friday, August 09, 2019:

Thanks for the replies. Gaurav is correct, I was using the wrong defines. Based on the behavior I wasn’t sure if it was related to something I was missing with the initialization or something I was missing with respect to FreeRTOS initialization. Thanks again.