xQueueReceive FreeRTOS hardfault NRF52840

It is my first time running FreeRTOS on NRF52 and I would really appreciate any help to figure out the root cause for the hard fault. I run a simple FreeRTOS application with 2 tasks. The application receives UART data and loops it back. The system starts fine and runs fine for 1 – 2 mins and then the hard fault happens in xQueueReceive function. The call stack screen shot is attached: As the stack shows the hard fault happens in the DSB instruction inside the portYIELD() macro. I’ll appreciate any ideas about the root cause of the issue. Best Regards, Anton

xQueueReceive FreeRTOS hardfault NRF52840

First a couple of points. The stack frame shows queue.c going to cmsis_gcc.h – if that is the true stack frame then the port is not something we have provided our selves (FreeRTOS on Cortex-M predates CMSIS, and even if it didn’t we generally don’t take dependencies on third party code within the kernel). In any case, that is probably the stack from of the exception handler, not the stack frame of the code that caused the exception. There is code on this page https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html that shows you how to get the stack frame of the code that actually generated the exception…..but before going there: Have you gone through this page to see if it gives you any ideas of what might be wrong? https://www.freertos.org/FAQHelp.html For a start it is best to be using a recent (at least 10.1.x) version of FreeRTOS with configASSERT() defined as that will catch nearly all (if not actually all) interrupt priority misconfigurations that can lead to issues. Also make sure to double check stack depths. The linked page describes both of those points.

xQueueReceive FreeRTOS hardfault NRF52840

Hi Richard, thanks a lot for your answer. I have followed the instructions and implemented my own hard fault handler and got the same result. The SP register points to the same instruction – DSB in the portYIELD macro. You have also a valid point that the port doesn’t come from you. It is provided by Nordic Semiconductor and I think it will be right to make a support case with Nordic. Best Regards, Anton