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

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.

You are probaly using the wrong defines there. The code should look like the following: ~~~ SCB->SHCSR |= ( SCBSHCSRMEMFAULTENA | SCBSHCSRBUSFAULTENA | SCBSHCSRUSGFAULTENA ); ~~~

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.