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?

  • Hi, 

    Did you inherit some legacy code that uses

    I wanted to port the secure dfu example which uses app_timer/app_scheduler to work with freertos.

  • I understand your efforts, but this is something we have not tested in an RTOS setup.

    There are tons of checks withing the FreeRTOS kernel that might not like a context to be executed within a critical section. I think that is what is happening in your case. 

    I have not seen how the app_scheduler is used in this dfu example, If app_sched_event_put is not used from many different contexts, it should not hard to phase out app_scheduler and use a separate task and a semaphore/mutex to change the execution context from one to another in freertos.

Reply Children
No Data
Related