Information about weird LPTIM compare match behavior. (stm32L462RE)

[PGoud]

Datasheet: "Interrupt flag is raised when the content of the Counter register (LPTIM_CNT) matches the content of the compare register (LPTIM_CMP)."

Some forums: "Compare match Interrupt flag is raised if CNT >= CMP and not CNT = CMP"

(Cf. https://community.st.com/s/question/0D53W000004J0srSAC/stm32l0-lptim-generating-random-compare-match-interrupt-when-changing-compare-match-value )

Can we have detailed information about this "quirck" ?

On my side, using continuous mode, I can indeed see some "erroneous" CMP interrupt very few time (one count more ?) after having set CMP register to a value lower than current CNT ???

Notice that when seting CMP register, CMP interrupt is disable, CMP_OK is correctly expected and received, and at this moment the CMP interrupt flag is not yet set.

Thanks for any detailed information about this.

[waclawek.jan]

> "Compare match Interrupt flag is raised if CNT >= CMP and not CNT = CMP"

Yes, this is how the "normal" timers behave, so it's likely the LPTIM behave in the same way.

I can also imagine reasons why the compare happens only after some LPTIM clock(s) later than CMP_OK, as the linked thread indicates.

The LPTIM chapter would need a thorough rework (and LPTIM deserves a better characterization in DS, too), but than that can be said of many if not all modules in STM32.

JW

[PGoud]

But still something strange with that because, sometimes the interrupt is not set with very similar context.

That's why I would really like an "official / ST" note about this case. Do you think they will never do that or update their documentation ?

[waclawek.jan]

There is no indication that ST plans significant overhaul of the documentation, or that they plan to add massive amounts of application notes expanding on the material in RM. In other words, the changes in documentation are mainly bugfixes and minor cosmetic changes.

> But still something strange with that because, sometimes the interrupt is not set with very similar context.

You can try to pester ST directly, but they would require clear explanation of what you mean by this anyway, so you may try here first, together with minial but complete compilable code to reproduce the problem, best in clean C using terms and register descriptions from the RM (i.e. no Cubisms or other "library" stuff).

JW