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

Proper way to monitor CPU load with GPIO while using FreeRTOS ?

Hi !

I'm running the ble_app_hrs_freertos example from SDK11 on the nRF52 dev. kit.

I would like to toggle some GPIOs to monitor the CPU activity and the FreeRTOS context. More specifically I would like to :

  1. Have a GPIO in logic state low while the CPU is asleep and in logic state high while the CPU is running (in softdevice, in a task, in an interrupt, etc.)
  2. Have a GPIO in logic state high while the CPU is working in the softdevice part and in logic state low when it isn't

Can you help me achieve this ? I already know how to monitor FreeRTOS tasks activity by redefining traceTASK_SWITCHED_OUT and traceTASK_SWITCHED_IN but I can't find how to monitore softdevice activity and the overall CPU activity. This also allow to monitor the Idle task activity, but it doesn't cover the softdevice and interrupts parts, does it ?

Here are my traceTASK_SWITCHED_OUT and traceTASK_SWITCHED_IN macros (25 being the GPIO I use for the Idle task) :

#ifndef traceTASK_SWITCHED_OUT
/* Called before a task has been selected to run.  pxCurrentTCB holds a pointer
to the task control block of the task being switched out. */
#define traceTASK_SWITCHED_OUT() if(xTaskGetIdleTaskHandle() == pxCurrentTCB)  \
	{ nrf_gpio_pin_clear(25); } \
	else { nrf_gpio_pin_clear((int)pxCurrentTCB->pxTaskTag ); }
#endif

#ifndef traceTASK_SWITCHED_IN
/* Called after a task has been selected to run.  pxCurrentTCB holds a pointer
to the task control block of the selected task. */
#define traceTASK_SWITCHED_IN() if(xTaskGetIdleTaskHandle() == pxCurrentTCB)  \
	{ nrf_gpio_pin_set(25); } \
	else { nrf_gpio_pin_set((int)pxCurrentTCB->pxTaskTag ); }
#endif
  • Hi Tim,

    With traceTASK_SWITCHED_IN you can trace the FreeRTOS side activity. but it is not possible to track softdevice activity as there are no debug plugins available to do it.The softdevice will wakeup when there is any events in the modules it owns and then goes to sleep again. I hope they add some plugin macros in future to extract this good info about the CPU usage.

  • Hello Aryan, thanks for your answer. Too bad it's not possible, it doesn't seem realistic to me not to be able to know the exact CPU active time. How can you say that any basic application is not taking 95% of CPU time if there's a part of the application you can't monitor ?

    In my opinion this kind of feature should be a priority for the softdevice team. It's ok to consider the BLE stack as a black box, but we should be able to know when this black box is active...

  • softdevice is released as hex files, so

    1. the debug macro plugin cannot help with the pre compiled hex files
    2. Softdevice decided not to waste space and resources by adding code to enable and disable the debug options through API.
      I have myself tried to get the CPU usage of softdevice activity while i was experimenting Segger SystemViewer and came across the challenge you are facing. I am not sure if everyone agrees with the priority of this feature going in, afterall this is a debug or benchmark feature and the SD activity has been always been a blackbox and they priotitize stability with BLE features.
  • Did you read the blog I wrote about instrumenting the softdevice with SystemView? It's here. You can get a very detailed picture of the interrupts which are driving the softdevice and show what it's doing, plus you can see how long it takes to service any of the SVC calls. With all the information in there you can put together a pretty accurate picture of how much time the softdevice is taking to do work.

    I didn't put that together with the FreeRTOS monitoring, I was running without an RTOS in that example, but it wouldn't be too difficult to do that too.

  • Thank you for the link and the article, it looks great. I'll try it within the day.

Related