CC2745R10-Q1: FreeRTOS tickless idle mode in SDK9.10 causes an assert.

Hello,

There some important information to consider when using tickless idle in Cortex-M chips: Low Power RTOS For ARM Cortex-M MCUs - FreeRTOS. In addition, you may need to implement the following macro: https://freertos.org/Documentation/02-Kernel/02-Kernel-features/07-Lower-power-support#the-portsuppress_ticks_and_sleep-macro

It may be that the issue is caused by incorrect configuration of this feature.

Best,

Nima Behmanesh

Hello,

Is it possible to set configUSE_TICKLESS_IDLE to a value other than 1 in Sysconfig1.23.1?

If not, please tell me why 1 is recommended.

Currently, I have manually changed configUSE_TICKLESS_IDLE to 2.

Also, the assert occurs regardless of whether the setting is 1 or 2.

Hello,

I'll ask my colleagues and will get back to you Monday.

Best,

Nima Behmanesh

Hello,

How about this matter?

Hello,

Toshiki Nakamura said:

Currently, I have manually changed configUSE_TICKLESS_IDLE to 2.

Based on the FreeRTOS documentation, setting this to two would mean that you will need to implement the necessary functions for using tickless idle. Setting it to one would use whatever we have implemented: https://freertos.org/Documentation/02-Kernel/02-Kernel-features/07-Lower-power-support#the-portsuppress_ticks_and_sleep-macro:

Built in tickless idle functionality is enabled by defining configUSE_TICKLESS_IDLE as 1 in FreeRTOSConfig.h (for ports that support this feature). User defined tickless idle functionality can be provided for any FreeRTOS port (including those that include a built in implementation) by defining configUSE_TICKLESS_IDLE to 2 in FreeRTOSConfig.h.

This means that you must implement portSUPPRESS_TICKS_AND_SLEEP. However, this also depends on the power driver in the device. 

I'd recommend keeping it to 1. It's also default to 1 in our projects.

I'm not able to reproduce this issue on my end, so I'm not entirely sure why it's being asserted.

Are you using a custom board? What modifications have you made to the project?

Best,

Nima Behmanesh

Additional question

In our project, we set Power_idleFunc() as the FreeRTOS Idle Hook Functions in SysConfig.

We found that the assert in question was occurring in the route of Power_idleFunc(), which is called directly from vApplicationIdleHook().

If configUSE_TICKLESS_IDLE = 1, there is also a route of Power_idleFunc() called from vPortSuppressTicksAndSleep(),
which means that Power_idleFunc() is called from two places in prvIdleTask(). Is this a problem?

If PowerCC27XX_standbyPolicy is set as the Power - Policy Function, shouldn't Power_idleFunc be set as the Idle Hook Function?

Hello,

Toshiki Nakamura said:

If PowerCC27XX_standbyPolicy is set as the Power - Policy Function, shouldn't Power_idleFunc be set as the Idle Hook Function?

The idle hook function is called before the power management hook function. So in your case, if you set the power management function as both an idle hook and in the power policy, you would be calling it during the idle function as well as after. 

Toshiki Nakamura said:

If configUSE_TICKLESS_IDLE = 1, there is also a route of Power_idleFunc() called from vPortSuppressTicksAndSleep(),
which means that Power_idleFunc() is called from two places in prvIdleTask(). Is this a problem?

Without testing, I wouldn't be able to say that this would cause a problem, but knowing the flow: Idle Hook -> Power Management Function, I'd say to avoid repeating the same power management function twice.

Any power related functions (like a power policy) should go into the Power section of Sysconfig:

That way you won't have any redundant function calls.

Hope that helps!

Best,

Nima Behmanesh.