The match interrupt on LPTIMx->CCRx is triggered when LPTIMx->CNT > LPTIM->CCRx - not on equal (=) as one might expect

[_andreas]

On the STM32U5xx, ST decided to keep this interpretation of "match". It is present on other chips as well, see

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

This has the side effects that

1. it will be always one tick late
2. you can't match the LPTIMx->ARR value
3. An interrupt will be triggered if you load a CCR < CNT

[waclawek.jan]

Are you sure it's not >= ?

The LPTIM documentation is, well, lacking.

JW

[_andreas]

@Community member​ 

I've made a test and the result was stable. In my case, the LPTIM is clocked from 32768 Hz watch crystal, in a simple up counter configuration with ARR at 0xffff (the init code is ugly, so I did not post it).

In the ISR, I've recorded the CNT and CCR values, and it was always CNT > CCR, e.g. CCR = 0x8001 and the ISR was triggered at CNT 0x8002. It takes about 1.25us to enter the ISR, so with 30.5us before the next tick: yes, I'm sure. It also fits the description in the provided link. The link also mentions a silicon bug, which blocks the MCU at the entrance of the ISR until CNT > CCR, so for ~ 1 tick (30.5us). I've not checked whether this bug is present on the STM32U5xx.

[waclawek.jan]

Thanks.

JW