• State Verified Answer
  • Replies 8 replies
  • Subscribers 73 subscribers
  • Views 1799 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 245166
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Profiling FreeRTOS and softdevice

TS Gowtham

Hi,

I'm using the nRF52832 with FreeRTOS and SDK 14.2.0 . I took a look at Profiling the Softdevice and FreeRTOS with Segger SystemView and Instrumenting with Segger SystemView . But both these blog posts have the lib file only for s132 v2.0.0 . So, has the required hooks been included in the latest version of the softdevice? Or is there any method from which I can get systemView or any instrumentation software working? Does Nordic have any suggested methods for this?

Thanks

  • 0

    Hi Gowtham,

    The files that are provided in that article by RK was done by reverse engineering the hex file.We have not allowed any hooks in any softdevice to be able to profiles as this consumes memory and introduces latencies.

    I am guessing that you want to do this only for educational purpose and have is not a blocker for your implementation.

  • 0 in reply to Susheel Nuguru

    Hi Sushel,

    I'm actually porting a production code to FreeRTOS and I'm having multiple issues with incorrect priorities for the tasks and timers. So, I thought that profiling would help me with this. Is there any other debug method or something to optimize the priorities?

  • +1 in reply to TS Gowtham

    I understand your approach. But if your application interrupts is not using interrupt priorities used by the softdevice interrupts, then you should not worry about the need of critical section due to softdevice interrupting your application.

    But you need to consider the conflicts in priorities within the application interrupts and the need of critical sections to avoid race conditions and/or deadlocks.

    In terms of FreeRTOS, all the tasks are running in Thread priority, which is the least priority in the Cortex-M4 system on which nRF52832 is built. 

    I can confidently say that if you have not used the softdevice reserved priorities for any of your application interrupts (not configuring the priority of any interrupt will take a default value of priority 0, which conflicts with softdevice priority) then you do not need to worry about softdevice stealing the CPU in middle of something. The race conditions will be caused by SD only if there are priority conflicts between application and softdevice.

    In this case, I am quite confident that the conflict is between your application priorities (interrupts or RTOS tasks)

  • 0 in reply to Susheel Nuguru

    Hi Susheel,

    As you have mentioned, I have not modified any of the interrupt priorities in sdk_config.h. My application does not use any of the interrupts, it only uses FreeRTOS tasks.

    I'll take up your advice and concentrate on the task priorites. Any suggested method for profiling just the FreeRTOS tasks?

    I've tried the RTOS thread awareness in SES but that keeps throwing up errors. And I've tried SystemView but couldn't apply the patch mentioned in this link as I'm using the RTC and not the systick ( my app is based on the freertos hrs example).

    Thanks,

    Gowtham

  • 0 in reply to TS Gowtham

    I have tried profiling the HRS_FreeRTOS example months ago and it went ok. I have not realized that the later versions of SES/SystemView have glitches. I do not think our FreeRTOS port works with Systick. It needs to be RTC like what you have set

Related
Terms of service