cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L476 LPTIM1 counter register

turboscrew
Senior III
Posted on October 06, 2017 at 21:42

I know the counter register read is not very reliable:

Bits 15:0 CNT: Counter value

When the LPTIM is running with an asynchronous clock, reading the LPTIM_CNT register may

return unreliable values. So in this case it is necessary to perform two consecutive read accesses

and verify that the two returned values are identical.

It should be noted that for a reliable LPTIM_CNT register read access, two consecutive read

accesses must be performed and compared. A read access can be considered reliable when the

values of the two consecutive read accesses are equal.

But how many reads is normal?

I tried to find the 'edge' by:

uint32_t read_count()

{

    uint32_t tmp1, tmp2;

    tmp1 = HAL_LPTIM_ReadCounter(&hlptim1); // hlptim1 is a global variable

    while ((tmp2 = HAL_LPTIM_ReadCounter(&hlptim1)) != tmp1) tmp1 = tmp2;

    return tmp1;

}

uint32_t poll_count_change()

{

    uint32_t tmp;

    tmp = read_count();

    while (read_count() == tmp);

    return get_systicks();

}

the worst case seemed to be that the poll_count_change() took about 45ms!

Is that anywhere near normal?

The LPTIM1 was running on LSE and with prescaler 2 and the processor was running @ 48MHz.

#stm32l4 #lptim
1 ACCEPTED SOLUTION

Accepted Solutions
Posted on October 07, 2017 at 12:29

Please note, that I am not ST.

you mean bus clock (80 mHz)? 12.5 ns * 16 bits = 200ns?

(Please use capital M for Mega prefix)

I mean maximum input frequency to LPTIM's counter input, not the bus clock.

Unfortunately, ST does not specify this; even techsupport could not tell this last time I asked (I was just curious and was not that interested to push this any further). It may be the same as other timers' value (i.e. 80MHz as you've sayd), but it also may be lower, if they used longer transistors in the counter to lower power consumption. But even then I would be surprised if it would be slower than 2-3x the 80MHz rate.

In other words, if you are confident you are reading the LPTIM way faster than it is clocked, then IMO, you should have a stable reading within say 1us. I can't explain your findings and you probably should contact ST through FAE or the support form on web to get further explanation or help.

JW

View solution in original post

13 REPLIES 13
Posted on October 06, 2017 at 22:34

IMO the reason for 'unreliability' is that the read might sample the counter while an input pulse ripples through the stages. In other words, it should be 'unstable' only after the vicinity of the input pulse; duration of the 'ripple' should be less than or comparable to (1/maximum clock) x counter bits. Thus, if the input clock is nowhere near this (which it isn't), and you run system clock at the maximum, the reading should be stable within a dozen of system clocks.

I don't quite understand your method though.

JW

turboscrew
Senior III
Posted on October 07, 2017 at 10:20

The read_count() reads until it gets two same values with adjacent reads, an the poll uses that reading and checks when the value changes. With the formula, you mean bus clock (80 mHz)? 12.5 ns * 16 bits = 200ns?

We have a good oscillator for the HSE, except that it's a bit power hungry, and to save battery, we put the device into stop2 mode and switch off the oscillator for most of the time. The system operates in 1s cycles, and the system clock precision needs to be 'carried' over the sleep time such that the error is less than 10 us. The LSE xtal is good enough. The problem is 'transferring' the time from systick to lptim before sleep, and from lptim back to systick after the sleep.

turboscrew
Senior III
Posted on October 07, 2017 at 12:33

I guess it's at least 80 MHz, because the LPTIM can use APB clock as a clock source...

And I guess the same applies to all low power peripherals clocked by a low power side clock (LSE/HSE) - including RTC?

Also, what are the two LPTIM_CFGR fields COUNTMODE and CKSEL?

The explanations in the reference manual look confusing.

Bit 23 COUNTMODE: counter mode enabled

The COUNTMODE bit selects which clock source is used by the LPTIM to clock the counter:

0: the counter is incremented following each internal clock pulse

1: the counter is incremented following each valid clock pulse on the LPTIM external Input1

Bit 0 CKSEL: Clock selector

The CKSEL bit selects which clock source the LPTIM will use:

0: LPTIM is clocked by internal clock source (APB clock or any of the embedded oscillators)

1: LPTIM is clocked by an external clock source through the LPTIM external Input1
Posted on October 07, 2017 at 12:29

Please note, that I am not ST.

you mean bus clock (80 mHz)? 12.5 ns * 16 bits = 200ns?

(Please use capital M for Mega prefix)

I mean maximum input frequency to LPTIM's counter input, not the bus clock.

Unfortunately, ST does not specify this; even techsupport could not tell this last time I asked (I was just curious and was not that interested to push this any further). It may be the same as other timers' value (i.e. 80MHz as you've sayd), but it also may be lower, if they used longer transistors in the counter to lower power consumption. But even then I would be surprised if it would be slower than 2-3x the 80MHz rate.

In other words, if you are confident you are reading the LPTIM way faster than it is clocked, then IMO, you should have a stable reading within say 1us. I can't explain your findings and you probably should contact ST through FAE or the support form on web to get further explanation or help.

JW

Posted on October 07, 2017 at 12:34

(Please use capital M for Mega prefix)

Oops, typo...

Posted on October 07, 2017 at 12:50

Also, what are the two LPTIM_CFGR fields COUNTMODE and CKSEL?

34.4.10  Counter mode deals with them further, but as I've said I am not using the LPTIM at the moment so am not going to dig deeper.

JW

Posted on October 07, 2017 at 13:14

And I guess the same applies to all low power peripherals clocked by a low power side clock (LSE/HSE) - including RTC?

RTC is way different. It can't be clocked by external sources; its counter has an asynchronous (ripple) and synchronous section and there's no way to read out the asynchronous one. There's a synchronization mechanism ('shadow registers') built in, but for a different reason - there are several registers which have to be read out from the RTC (date, time, subseconds) and usually it's required they all being in consistent state (that that mechanism is subject to errata is another issue). When that mechanism is switched off, there's another requirement for the APB being at least 7x faster than the RTC clock, which hints that there is some per-register synchronisation mechanism built in even for that case.

JW

Posted on October 07, 2017 at 14:19

Truckload of thanks!

Posted on February 14, 2018 at 16:53

Hi

        I am trying to use the LPTIM and I want to clock out of HSI 16MHz clock. It does not clock out of 16MHz. However setting the APB clock to clock the LPTIM works. Can you please send me the snippet of code you have used to clock out of HSI clock?. Meaning if i want to set HSI clock to clock the counter and prescale of 16 then I can set the tick to 1microsecond... That is what I want... Thanks.

Regards

Bala