4.0.2 Tick timing incorrect after swapping clock configuration

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

4.0.2 Tick timing incorrect after swapping clock configuration

602 Views
fcw
Contributor IV

Very long story made short, it appears that tick timing get bollixed after changing clock configurations.

Demo this by:

  printf( "pre: %d\n", _time_get_hwticks_per_tick() );

_bsp_set_clock_configuration( <config other than startup> );

  printf( "post: %d\n", _time_get_hwticks_per_tick() );

pre and post values the same... If core clock changes, _hwticks_per_tick should change.

Result of not changing is that time becomes non-monotonic.

If this a bug and not something messed up in my BSP, the bug is in _bsp_set_clock_configuration()

- It calls CPU_SetClockConfiguration()

- then calls hwtimer_set_freq() to update the timer modulo, but does not update kernel_data->HW_TICKS_PER_TICK

- exits.

- any following tick-related call uses the bogus kernel_data->HW_TICKS_PER_TICK

In my BSP, I fixed the problem by calling _time_set_hwticks_per_tick() after the call to hwtimer_set_freq()

NXP: Bug in MQX or something mucked up in my BSP as it was built?

Also, in the process of chasing this down I came across _time_set_resolution() which states:

     kernel_data->HW_TICKS_PER_TICK = resolution * 1000;

... which is not correct.

0 Kudos
2 Replies

418 Views
soledad
NXP Employee
NXP Employee

Hello Fred,

Please check the below thread and let me know if this helps.

MQX 3.8 _time_get() -&gt;_time_to_date defect 


Have a great day,
Sol

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

418 Views
fcw
Contributor IV

Sol,  Thank you  for the reply, but that 3.8 thread isn't addressing the same problem. Many of the tick-related functions call the macro PSP_NORMALIZE_TICKS(tick_ptr) which for Kinetis, at least, resolves to _psp_normalize_ticks((PSP_TICK_STRUCT_PTR)(tick_ptr)).

Take a look at _psp_normalize_ticks() in mqx\mqx\source\psp\cortex_m\psp_tinm.c:

Line 45 assigns:

     ticks_per_tick = kernel_data->HW_TICKS_PER_TICK;

Then in line 48:

     register uint32_t t = tick_ptr->HW_TICKS[0] / ticks_per_tick;

What I pointed out in my question is that when changing the clock configuration:

-- hwtimer_set_freq() is called to update the Systick timer modulo such that it continues to reset itself and generate an interrupt at a 200 Hz rate. For example, if MQX is configured for a 200 Hz RTOS tick with a 24 MHz core clock, hwtimer_set_freq() sets the modulo to 24000000/200 = 120000. If the core clock is changed to 96 MHz, the modulo becomes 96000000/200 = 480000.

-- Since kernel_data->HW_TICKS_PER_TICK does not get updated when the core clock changes, the statement at line 48 in _psp_normalize_ticks() gets the wrong answer.

-- Calling _time_set_hwticks_per_tick() as mentioned in the post updates kernel_data->HW_TICKS_PER_TICK so _psp_normalize_ticks() gets the right answer.  The point is that it seems this should be done somewhere in _bsp_set_clock_configuration().

fcw

0 Kudos