xQueueReceive FreeRTOS hardfault NRF52840

antonl wrote on Monday, April 22, 2019:

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

rtel wrote on Monday, April 22, 2019:

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.

antonl wrote on Tuesday, April 23, 2019:

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