_time_delay in low power clock configurations (CW10/MQX/Kinetis)

[TugboatCaptain]

Should the _time_delay function cause a task to sleep for roughly the same duration in any clock mode and/or in VLPR mode?

i.e. should the following _time_delay calls all delay for approximately the same amount of time?

    _time_delay(10);

    _lpm_set_clock_configuration(BSP_CLOCK_CONFIGURATION_2MHZ)

    _time_delay(10);

    _lpm_set_operation_mode(LPM_OPERATION_MODE_WAIT)  //VLPR

    _time_delay(10);

    _lpm_set_operation_mode(LPM_OPERATION_MODE_RUN)

    _time_delay(10);

    _lpm_set_clock_configuration(BSP_CLOCK_CONFIGURATION_DEFAULT)

    _time_delay(10);

(actual code does check for error returns, question assumes no other ready tasks, BSP_ALARM_FREQUENCY==200 so it is understood delay resolution is 5ms)

It seems like the systick_config() call within _bsp_set_clock_configuration() does this compensation for the clock configuration.  And it appears _lpm_set_operation_mode keeps idle task from hanging.

note: I am using CW10.2 and MQX3.8  with Kinetis k60f and I understand from the MQX4.0 release notes there are known prior code issues with VLPR, but I need to know if by design the time delay should stay consistent in these modes.

Thanks.

[TugboatCaptain]

Thanks David and Martin, my testing confirms your info, the _time_delay(10)  takes between 5-10msec.  The variability I was seeing was related to the processor mode change line of code.  I will work through that...

Best regards,

'Cap

[DavidS · Accepted solution]

Hi TugboatCaption,

To add to what MartinK said, the _time_delay(); function call passes a millisecond variable that gets converted to ticks. This tick value is then registered to the RTOS for it to wake up the calling task in the future. Each time a tick (or some async event is causing the scheduler to look for expired timer) occurs the RTOS looks for expired timers to then enable the task to resume.

For low power modes the _lpm_set_clock_configuration(); will set the clock to desired frequency and then update the systick timer (SYST_RVR) to generate the BSP_ALARM_FREQUENCY (200 ticks oer second) for new clock setting thereby preserving the heart beat of the system from a tick clock point of view.

Regards,

David

[c0170]

Hi TugboatCaptain,

it should take the same time, but be caution _time_delay could vary by one tick which can lead to different times depending on the resolution. Here's an example :

_time_delay(10) (adelay resolution 5ms). This might produce a delay between 5 to 10ms.

Regards,

MartinK