Profiling FreeRTOS and softdevice

RE: Profiling FreeRTOS and softdevice

TS Gowtham — Fri, 13 Mar 2020 04:42:55 GMT

Thanks, I'll try running SystemView once on the HRS FreeRTOS example before trying it on my code.

RE: Profiling FreeRTOS and softdevice

Susheel Nuguru — Tue, 10 Mar 2020 09:31:10 GMT

I used SystemViewer and unfortunately I did not make any notes of what changes I was making to make it work. But it did work wonderfully to profile the HRS freertos example we have in the application. The profiling was done just as a hobby to feed my curious mind. Sorry, I guess this information is not of much use to you.

RE: Profiling FreeRTOS and softdevice

TS Gowtham — Sun, 08 Mar 2020 13:47:42 GMT

Hi,

What tools did you use for profiling? Can you provide any links or guides please?

RE: Profiling FreeRTOS and softdevice

Susheel Nuguru — Sun, 08 Mar 2020 12:46:47 GMT

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

RE: Profiling FreeRTOS and softdevice

TS Gowtham — Fri, 06 Mar 2020 05:41:50 GMT

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

RE: Profiling FreeRTOS and softdevice

Susheel Nuguru — Thu, 27 Feb 2020 07:42:14 GMT

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)

RE: Profiling FreeRTOS and softdevice

TS Gowtham — Wed, 26 Feb 2020 14:48:42 GMT

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?

RE: Profiling FreeRTOS and softdevice

Susheel Nuguru — Wed, 26 Feb 2020 13:54:12 GMT

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.