FrreRTOS runtime analysis API usage for NXP S32K plaform

Partners & Sponsors NXP
, ,
1

Hello,

Working on NXP S32K114, we have integrated frreRTOS successfully.
We want to use Runtime analysis API to moitor runtime data of the task.

Can someone help with following queries? FYI : Clock tick is 1msec (FIRC is configured as 60 MHz ), minimum task time is 10 msec

  1. Which clock to be used ? LPTMR OR LPIT
  2. AS PER Documentation, for Runtime analysis trigger should be 10-20 times faster than the task time, what value to be used for trigger? 0.01 msec?
  3. If we use 0.01 as trigger for LPIT timer ? what can be the clock source? Bus clock ?
2

I’ve worked with the S32K344. Use the LPIT at 10Khz, which is 10x your tick rate.

S32DS has built in FreeRTOS analyzing tools that will allow you to look at CPU and memory usage per task.

Hope it helps!

1 Like
3

Welcome to the forums @amicheda! Given your question is board specific I’d recommend also posting on the NXP community forums. Users there should be able to give you more detailed directions for your use case.

In general, if your clock is set to 1msec (or 1Khz) you’ll want to use a trigger with a frequency of 10Khz (0.1msec) - 20Khz (0.05msec).

1 Like
4

@kstribrn : Thank you for the quick update.

5

@MateoSegura : Thank you for the quick response.
are you referring to below option in S32K tool?

image
image1698×216 59.4 KB

6
  1. How often the runtime is updated for each task and how it is achieved
  2. Did you use ISR based mechanism to update task runtime for each timer tick (for eg 250us)
7

I’m not sure if this is the built in tool - having not used this platform before - @MateoSegura can answer this better. This does give you the percent stack usage which gives you the overall stack usage since you can take your stack size (in words) * word size (in bytes) * percent utilized to give you the approximate memory usage (in bytes) for that task. I say approximate as the heap usage can fluctuate during task execution.

The runtime metric gives you the percentage of time that task has been running overall. So in this case, if you checked this stat after 100s, the IDLE task was running for ~87.5 seconds.

8

To your questions…

  1. The runtime is updated each time a context switch happens. This means the actual running task may not have the most accurate runtime. In your case, it appears that your IDLE task is happening frequently - so this may not be a problem for you. The total exceution time is based on the stats timer you configure (which is 10->100x faster than the Tick ISR) so you’ll have good accuracy.
  2. Kinda-sorta. The context switch is most often (though not always) triggered by the Tick ISR.

For more, see this page. The task header and source file may also be useful to you.