topic 4.0.2 Tick timing incorrect after swapping clock configuration in MQX Software Solutions

4.0.2 Tick timing incorrect after swapping clock configuration

fcw — Fri, 27 Jan 2017 00:32:38 GMT

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.

Re: 4.0.2 Tick timing incorrect after swapping clock configuration

soledad — Mon, 30 Jan 2017 22:38:47 GMT

Hello Fred,

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

MQX 3.8 _time_get() ->_time_to_date defect

Have a great day,
Sol

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

Re: 4.0.2 Tick timing incorrect after swapping clock configuration

fcw — Sat, 04 Feb 2017 17:15:46 GMT

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:

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