cancel
Showing results for 
Search instead for 
Did you mean: 

RTC smooth calibration on STM32L072CZ

Jonathan Roberts
Associate II
Posted on April 03, 2018 at 20:32

Hi all,

Summary: With external 32.768kHz crystal and RTC PREDIV_S=32767 and PREDIV_A=0 I cannot RTC configure smooth calibration correctly, specifically it seems impossible to set the CALP bit in the CALR register.

Details:

I am working on a project at the moment using the STM32L072CZ as part of the Murata 

CMWX1ZZABZ-091 module on the 

B-L072Z-LRWAN1 LoRa board. Our application uses the HAL and drivers from the  

http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/i-cube-lrwan.html

 1.1.4 package. The RTC is clocked from the external 32768Hz crystal.

For various reasons we needed to reduce the timestep used for the subsecond register in the RTC from the default of 0.976ms (PREDIV_S=1023, PREDIV_A=31). We initially tried the maximum (PREDIV_S=32767, PREDIV_A=0) which gives a timestep of 0.03ms, which works perfectly at the expense of more power. The issue is that this has broken the smooth calibration functionality. Digging into it we appear to have a problem with setting the RTC CALR register in HAL_RTCEx_SetSmoothCalib(). Specifically it seems to be impossible to set the CALP bit. For example if we want to add 5 clock pulses over a 32 second period we would call this function with the +512 pulses flag set and the minus pulses set to 507. This should result in CALR =0x81fb, but it is actually set to 0x1fb. The same can be seen by manually changing the register in the debugger (after the registers have been unlocked).

The same code works fine with a 0.976ms timestep 

(PREDIV_S=1023, PREDIV_A=31) and it also appears to work with a 0.122ms timestep (PREDIV_S=8191, PREDIV_A=3).

Has anybody else encountered this?

Thanks

Jonathan♯♯

#stm32l0 #rtc #smooth-calibration
1 ACCEPTED SOLUTION

Accepted Solutions
Posted on April 03, 2018 at 22:52

Has anybody else encountered this?

The chip developers have, apparently:

0690X0000060APZQA2.png

JW

View solution in original post

2 REPLIES 2
Posted on April 03, 2018 at 22:52

Has anybody else encountered this?

The chip developers have, apparently:

0690X0000060APZQA2.png

JW

Posted on April 04, 2018 at 10:16

How on earth did I miss that! Thanks for pointing out the obvious .