4.0.2 Tick timing incorrect after swapping clock configuration

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

4.0.2 Tick timing incorrect after swapping clock configuration

1,346件の閲覧回数
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 件の賞賛
返信
2 返答(返信)

1,162件の閲覧回数
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 件の賞賛
返信

1,162件の閲覧回数
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 件の賞賛
返信