FreeRTOS: Context switch hardfault

RE: FreeRTOS: Context switch hardfault

CheMax — Tue, 08 Oct 2019 13:45:02 GMT

I apologize for the long absence and silence in this topic, I was on vacation in connection with the birth of my daughter.

Yes, the problem was similar in the incorrect organization of access to a shared resource (pointer to data). Plus, you must correctly prioritize threads (and interrupts).

I believe that the answer was received during the discussion. the correct answers in my opinion I marked

RE: FreeRTOS: Context switch hardfault

Susheel Nuguru — Wed, 31 Jul 2019 05:57:29 GMT

[quote user="CheMax"]At the moment, after changing priorities, the problem situation is not repeated anymore. But the question is: what exactly the reason remains unanswered[/quote]

Any task synchronizing mechanism could cause a temporary priority inversion and this is expected. But this should not cause a stack corruption as this is allowed and like I said very much expected. It looks like the sanity of the data pointers in your lower priority thread is not checked before being dereferenced. Seems like you have some design flaw in how the two tasks communicate. I would recommend you to atleast check the sanity of the data pointers being used if they are accessed by more than one task.

RE: FreeRTOS: Context switch hardfault

CheMax — Mon, 29 Jul 2019 05:16:08 GMT

Good Moning,
No, I use queue module from NRF SDK (nrf queue.c \ nrf queue.h).

It seemed to me that it is more flexible (and yes, I like its API) and is better suited for my tasks (data damping before and after processing).

At the moment, after changing priorities, the problem situation is not repeated anymore. But the question is: what exactly the reason remains unanswered (

RE: FreeRTOS: Context switch hardfault

Vidar Berg — Fri, 26 Jul 2019 09:47:00 GMT

Hi, I don't think priority inversion should lead to corruption and writes to an arbitrary memory area, but I'm also not sure what's causing the memory corruption. Did you consider to use the Freertos module for Queing? https://www.freertos.org/a00018.html

RE: FreeRTOS: Context switch hardfault

CheMax — Fri, 12 Jul 2019 10:58:35 GMT

Hi,

I saw this post earlier when I did a preliminary search for possible problems before adding a queue module to the code. And even copied the proposed corrections just in case.

My question is related to this section of the code:

/**@brief Macro for entering a critical region.
 *
 * @note Due to implementation details, there must exist one and only one call to
 *       CRITICAL_REGION_EXIT() for each call to CRITICAL_REGION_ENTER(), and they must be located
 *       in the same scope.
 */
#ifdef SOFTDEVICE_PRESENT
#define CRITICAL_REGION_ENTER()                                                             \
    {                                                                                       \
        uint8_t __CR_NESTED = 0;                                                            \
        app_util_critical_region_enter(&__CR_NESTED);
#else
#define CRITICAL_REGION_ENTER() app_util_critical_region_enter(NULL)
#endif

/**@brief Macro for leaving a critical region.
 *
 * @note Due to implementation details, there must exist one and only one call to
 *       CRITICAL_REGION_EXIT() for each call to CRITICAL_REGION_ENTER(), and they must be located
 *       in the same scope.
 */
#ifdef SOFTDEVICE_PRESENT
#define CRITICAL_REGION_EXIT()                                                              \
        app_util_critical_region_exit(__CR_NESTED);                                         \
    }

Interrupts will be temporarily disabled and then allowed. If you use these functions in tasks with low priority, can a situation of knowledge be known as priority inversion (a low-priority thread blocks a high-priority)?

As far as I understood, I had the following: the simultaneous occurrence of high priority interruption and the process context switching process. At the same time, the contents of the registers (R0 - R12) seemed to overlap and instead of being saved to the stack, they were saved into an arbitrary memory area.
This can be taken as an explanation of the situation when the contents of the data buffers had the form of code located in the stack area.

I could investigate this issue in detail if there is a profiler, Segger SysView for example. But I had difficulties with its integration into the project. An example that you have created for the stack s132 and nrf52832 device. Is it possible (or the availability of a ready solution for your team) to adapt that code under the stack s140 (nrf52840)?

RE: FreeRTOS: Context switch hardfault

Vidar Berg — Thu, 11 Jul 2019 13:28:43 GMT

Hi, good to hear that you have had progress. The Softdevice reserves some of the interrupt priorities (if you're using Bluetooth), but not sure how wrong interrupt priority would cause the data corruption. Maybe it could be related to the issue Jakub mentions here: https://devzone.nordicsemi.com/f/nordic-q-a/46916/nrf_queue-will-not-fit-in-region-unplaced_sections-on-nrf52810/185496#185496

RE: FreeRTOS: Context switch hardfault

CheMax — Thu, 11 Jul 2019 07:09:40 GMT

So, one more working day is progress. It looks like I did not take into account the real priority of interrupts and the requirements of the RTOS.

In the file FreeRTOSConfig.h describes the minimum priority level and the maximum for interrupts that use the RTOS api functions (with _fromISR).

I also did not notice that Nordic recommends (or requires?) the following levels of priorities (file app_util_platform.h):

#define _PRIO_SD_HIGH       0
#define _PRIO_SD_MID        1
#define _PRIO_APP_HIGH      2
#define _PRIO_APP_MID       3
#define _PRIO_SD_LOW        4
#define _PRIO_SD_LOWEST     5
#define _PRIO_APP_LOW       6
#define _PRIO_APP_LOWEST    7
#define _PRIO_THREAD        15

Indeed, the use of task priorities and priorities of interrupts MK is very complicated.

But I would like to get an answer to my question related to the use of the queue module in conjunction with the RTOS. Are there any restrictions or recommendations?

Thanks