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

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Jump to solution
933 Views
TugboatCaptain
Contributor III

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.

0 Kudos
1 Solution
89 Views
DavidS
NXP Employee
NXP Employee

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

View solution in original post

0 Kudos
3 Replies
89 Views
TugboatCaptain
Contributor III

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

0 Kudos
90 Views
DavidS
NXP Employee
NXP Employee

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

View solution in original post

0 Kudos
89 Views
c0170
Senior Contributor III

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