This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Unable to add FreeRTOS to Thread Secure DFU example

I ported the Thread Secure DFU example to use FreeRTOS, however I get a hard fault if something is scheduled using the app_timer provided.

Calling coap_dfu_trigger or handling a bsp button press results in

Can the app_timer/app_scheduler from nRF SDK be used together with FreeRTOS? 

Setup:

Segger Embedded Studio v5.10b
Nordic nRF52840
nRF5 SDK for Thread and Zigbee v4.1.0

Parents
  • Using the document "Analyzing HardFaults on Cortex-M CPUs (AN00016)", I think it's related to priorities for interrupts.

    Stepping out of the hard fault shows:

    With RADIO IRQ prio set to 0:

    Which is higher (lower number) then configMAX_SYSCALL_INTERRUPT_PRIORITY

    I have these in FreeRTOSConfig.h;

    #define configLIBRARY_LOWEST_INTERRUPT_PRIORITY       _PRIO_APP_LOWEST
    #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY  _PRIO_APP_HIGH
    #define configKERNEL_INTERRUPT_PRIORITY               configLIBRARY_LOWEST_INTERRUPT_PRIORITY
    #define configMAX_SYSCALL_INTERRUPT_PRIORITY          configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY

  • Can the app_timer/app_scheduler from nRF SDK be used together with FreeRTOS? 

    Hi, You should be using app_timer_freertos.c instead of using the app_timer.c (most likely you already know that).

    It should be ok to use app_timer_freertos/app_scheduler along with freertos. For me, in an architectural point of view, it is not necessary to use app_scheduler in an rtos environment. This module was created in a baremetal(non rtos based applications) to be able to change the context from one to the other. But in rtos you already have a tasks/thread concept which you should use instead of app_scheduler.

    I do not see any conflicts in your FreeRTOSConfig.h in terms of priority settings. Also it is not clear exactly what triggered the hardfault. Can you see if the hardfault instructions address is inside the protocol stack or in the application? It looks like a misuse of app_scheduler in a higher context which it is not supposed to be used. Why are you using app_scheduler in an RTOS environment? Did you inherit some legacy code that uses app_scheduler?

Reply
  • Can the app_timer/app_scheduler from nRF SDK be used together with FreeRTOS? 

    Hi, You should be using app_timer_freertos.c instead of using the app_timer.c (most likely you already know that).

    It should be ok to use app_timer_freertos/app_scheduler along with freertos. For me, in an architectural point of view, it is not necessary to use app_scheduler in an rtos environment. This module was created in a baremetal(non rtos based applications) to be able to change the context from one to the other. But in rtos you already have a tasks/thread concept which you should use instead of app_scheduler.

    I do not see any conflicts in your FreeRTOSConfig.h in terms of priority settings. Also it is not clear exactly what triggered the hardfault. Can you see if the hardfault instructions address is inside the protocol stack or in the application? It looks like a misuse of app_scheduler in a higher context which it is not supposed to be used. Why are you using app_scheduler in an RTOS environment? Did you inherit some legacy code that uses app_scheduler?

Children
Related