Tolerance of LPIT CVAL (Current timer value)

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

Tolerance of LPIT CVAL (Current timer value)

Jump to solution
2,416 Views
Hozumi
Contributor I

Regarding the CVAL (Current timer value) of NXP S32K144 LPIT, TRM states that "may not return the true value during operation"
However, could you clarify the tolerance of the values returned during LPIT running?

The lower bits of CVAL are truncated according to the required timer accuracy, so if the tolerance is within the truncated range, it can be used as the Current timer value.

0 Kudos
1 Solution
2,388 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,
This weakness is caused by limited functionality on the internal synchronization gasket between LPIT’s bus interface block and peripheral functional clock.
It’s not possible to provide max expected difference between the reads because it depends on the particular bit that hasn’t yet transitioned to the correct value.
To identify potentially wrong read of the CVAL, it’s recommended to use triple vote method.
Regards,
Lukas

View solution in original post

0 Kudos
9 Replies
1,665 Views
parth_rastogi10
Contributor III

Hi Lukas,

Regarding the reading of the CVAL of LPIT Driver, apart from reading in the ISR section which is already mentioned as the workaround for the errata the triple vote method is suggested to get the correct CVAL values. So, is this triple vote also can be added to the Errata workaround as an alternate solution for the CVAL Errata.

Please respond to the above query as soon as possible by tomorrow as it is an urgent need for the project.

Thanks,

Parth Rastogi
0 Kudos
1,650 Views
parth_rastogi10
Contributor III

Hi Lukas,

Can you please respond to the query that I posted for the workaround for reading CVAL.

@lukaszadrapa 

Thanks,

Parth Rastogi
0 Kudos
2,404 Views
Hozumi
Contributor I

On the otherhand, TRM (Rev. 12.1, 02/2020) states that "At any time, the current value of the timer for any channel can be read by reading the corresponding channel's CVALn register. The M_CEN bit must be '1' when doing so." in 48.5.2 page1549.

What are the conditions under which the LPIT CVAL does not return the correct value?

0 Kudos
2,389 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,
This weakness is caused by limited functionality on the internal synchronization gasket between LPIT’s bus interface block and peripheral functional clock.
It’s not possible to provide max expected difference between the reads because it depends on the particular bit that hasn’t yet transitioned to the correct value.
To identify potentially wrong read of the CVAL, it’s recommended to use triple vote method.
Regards,
Lukas

0 Kudos
2,311 Views
vienpeng
Contributor II

Hi, @lukaszadrapa, could you please introduce "triple vote method" in detail ? Is it  a 100% solution ?

0 Kudos
2,275 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

triple vote method means that you perform three consecutive reads and then evaluate the result. If there's uneven value, discard it.

The reads should be done as fast as possible. If it is done by CPU, use critical section, so no interrupt is triggered. Another option is to use DMA.

I got information that the possibility to read wrong value is higher if ratio between peripheral clock and bus clock is lower. If the ratio is 1/24, at least, it can still occur but probability is smaller and triple vote will eliminate the problem. Or, as already mentioned, use the same clock source (but triple vote is also needed).

Regards,

Lukas

 

0 Kudos
2,145 Views
Hirofumi
Contributor II

Hi, Lukas

About your comment "possibility to read wrong value is higher if ratio between peripheral clock and bus clock is lower"

Please tell me why this problem occur ?

0 Kudos
2,378 Views
Hozumi
Contributor I

Hi Lukas,

Depending on the relationship between the bus clock and the LPIT's count clock, can we read CVAL correctly?
For example, bus clock = LPIT's count clock.

0 Kudos
2,363 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

If the LPIT’s bus interface clock and peripheral functional clock are derived from the same clock source, it can significantly reduce the problem. However, it's not 100% solution. Still the triple vote should be used.

Regards,

Lukas

0 Kudos