Problem with LPIT

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Problem with LPIT

1,987 次查看
__invited__hari
Contributor V

I am using LPIT Timer Channel 0 of S32K148.

Seeing some sort of data misalignment with below example.

while(1) {

  uint32_t counterValue[20];

   for (uint32_t cnt = 0; cnt < 20; cnt++)

     counterValue[cnt] = *(volatile uint32_t*)0x40037024;

   for (uint32_t cnt = 0; cnt < 19; cnt++) {

     if (counterValue[cnt] < counterValue[cnt+1]) {

       DEBUG_PRINT_MSG ( "%010u (%02d) %010u (%02d)\n\r", counterValue[cnt], cnt, counterValue[cnt+1], cnt+1 );

     } else {

       DEBUG_PRINT_MSG ( "%010u (%02d)\n\r", counterValue[cnt], cnt);

    }

  }

}

Ideally the code shouldn't be reaching to the bold highlighted print message. Is there any reason why this can happen?

Below is the misaligned data observed through these buffer contents as reference.

4032996922 (00)
4032996918 (01)
4032996915 (02)
4032996927 (03)
4032996908 (04)
4032996905 (05)
4032996901 (06)
4032996898 (07)
4032996894 (08)
4032996891 (09)
4032996888 (10)
4032996884 (11)
4032996881 (12)
4032996877 (13)
4032996874 (14)
4032996871 (15)
4032996867 (16)
4032996864 (17)
4032996860 (18)

My SDK version is 2018.R1Beta 2.9.0

Timer initialization structure is here:

        /* lpit_user_config_t */
        {
            false,                                  /* enableRunInDebug       */
            false                                   /* enableRunInDoze        */
        },
        /* lpit_user_channel_config_t */
        {
            LPIT_PERIODIC_COUNTER,                  /* timerMode              */
            LPIT_PERIOD_UNITS_COUNTS,               /* periodUnits            */
            MAX_PERIOD_COUNT,                       /* period                 */
            LPIT_TRIGGER_SOURCE_INTERNAL,           /* triggerSource          */
            0U,                                     /* triggerSelect          */
            false,                                  /* enableReloadOnTrigger  */
            false,                                  /* enableStopOnInterrupt  */
            false,                                  /* enableStartOnTrigger   */
            false,                                  /* chainChannel           */
            false                                   /* isInterruptEnabled     */
        },

Thanks,

Hari

标签 (1)
标记 (2)
0 项奖励
6 回复数

1,406 次查看
danielmartynek
NXP TechSupport
NXP TechSupport

Hi,

The timer was not designed to be read in run time.

pastedImage_2.png

It was already discussed here:

LPIT TMR_CUR_VAL sporadically returning 0xFFFF'FFFF 

Thank you,

Daniel

0 项奖励

1,406 次查看
raul10
Contributor I

Does this only apply to the LPIT implementation of the S32K or also to that one of the KE1xF? There is no such hint in the manual but the LPIT seems to be similar.

0 项奖励

1,406 次查看
danielmartynek
NXP TechSupport
NXP TechSupport

Hi,

I'm not sure.

Can you post the question on https://community.nxp.com/community/kinetis community?

Thanks,

Daniel

0 项奖励

1,406 次查看
__invited__hari
Contributor V

Hello Daniel,

My plan was to use this timer (LPIT) for timeouts in low level drivers and it started giving this problem.

Can you suggest a 32bit timer I can use for this purpose? In fact I would be more happy if there are any 64bit timers supported by this Controller.

Thanks,

Hari

0 项奖励

1,406 次查看
danielmartynek
NXP TechSupport
NXP TechSupport

Hello Hari,

The LPIT timer can be still used in OC mode.

But you can use SysTick for drivers timeouts instead, it a 24-bit timer.

Regards,

Daniel

0 项奖励

1,406 次查看
__invited__hari
Contributor V

Hello Daniel,

This is so weird that S32K148 (ARM Cortex-M4) doesn't support with any 32bit free flow counter in real time.

OK. Let me digest this and try to use 24-bit counter for timeout check implementation for my drivers.

Now I need to switch my RTOS scheduler timer from this SysTick to LPIT/LPTMR.

Regards,

Hari

0 项奖励