Problem with LPIT

[__invited__hari]

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

[danielmartynek]

Hi,

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

It was already discussed here:

LPIT TMR_CUR_VAL sporadically returning 0xFFFF'FFFF 

Thank you,

Daniel

[raul10]

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.

[danielmartynek]

Hi,

I'm not sure.

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

Thanks,

Daniel

[__invited__hari]

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

[danielmartynek]

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

[__invited__hari]

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