I haven’t been able to attempt to reproduce this yet, though I wonder if it is to do with writing to DIER to soon after enabling the LPTIM. I’d be interested to know if adding a small delay after LL_LPTIM_Enable and before LL_LPTIM_EnableIT_CC1 helps.
In saying that, the team responsible for the CMSIS pack have identified a number of issues moving to a new version of ST’s firmware. They have some more fixes coming through shortly.
After setting the ENABLE bit, a delay of two counter clock is needed before the LPTIM instance is actually enabled.
Which repeats what ajudge suggested. I found a HAL_Delay of 1 also worked, 1ms is more than the 1/8192 seconds we are running the lptim at. To further that if the HCLK is lowered or the LPTIM CLK is increased I also do not see the hang.
The ST FW_U5_V1.9.0 was only released a few weeks ago, and seems to be the only version that exhibits this bug. I could not find the precise reason why our init code is only triggering the hang on this newer version of the ST firmware. However it seems likely that it is related to this change to LPTIM_DISABLE:
Annoyingly LL_LPTIM_IsEnabled does not seem to wait for this 2 cycle delay, so a sleep might be needed. Further, I do not see the LPTIM HAL code doing this delay after enable, so there may be more to the story here.
Something like this change will be added to our next release of the CMSIS pack.