cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L4 RTCCLK running slower than HSE frequency

Rea.David
Associate II
Posted on November 30, 2017 at 05:22

Hi All-

I'm using SW4STM32 with STM32CubeMx for configuration of an STM32L431RB MCU. I noticed that WakeUp events timed by the RTC appeared slow, and it appears that the RTC is being clocked from LSI rather than LSE as-configured.

In CubeMx, I have configured the RTCCLK source as LSE, and verified that the generated code sets this correctly. In the debugger's register view, I've confirmed that LSEON=1 and LSERDY=1, and that RTCSEL=01. (These values seem to persist, even after a chip erase and power cycle. This seems odd.)

I have confirmed that both LSI and LSE oscillators are running, and that LSE is at the correct frequency, by configuring PA2 as LSCO and measuring the output frequencies with LSCOSEL=0 (31.6KHz) and LSCOSEL=1 (32.76KHz).

However, when I configure PC13 as RTC_OUT_CALIB and set this to 512Hz, the output waveform is only at 504Hz (measuring between rising edges, as the reference manual advises), indicating that RTCCLK is somewhere around 32.2KHz. Curiously, this is the average of the measured LSI and LSE clock speeds, though I'm not sure how that could happen.

Any ideas why the RTCCLK is behaving so strangely? My next step is to create a cleanroom project in CubeMx that configures only the RCC and RTC to verify none of my other settings are causing any issues. If the problem recurs with that IOC file, I will post it here.

Thanks,

Dave

(Edit 20171130-0656EDT: Changed incorrect mention of 'HSE' to 'LSE')

#rtc #stm32l4-hal #cubemx-project
3 REPLIES 3
Rea.David
Associate II
Posted on November 30, 2017 at 13:11

I have generated a fresh STM32L431RBT project using CubeMx to verify that this behavior is unrelated to other configuration or user software running on the part. With RTCCLK configured for HSE, the

RTC_OUT_CALIB signal remains at 504Hz.

I have attached the IOC file used to obtain this result. The crystal on our board is an AbraconABS07AIG-768KHZ-6-1-T, with 12pF capacitors. I will also attempt to reproduce this result on a development board, though the closest thing I have is STM32L452RE.

Thanks,

Dave

________________

Attachments :

stm32l431rbt-rtc-hse-test.ioc.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyH7&d=%2Fa%2F0X0000000b5M%2FQoKmewi6dKtUV9JUONSkZrFjLMbQVcWFCsipoq7kDCA&asPdf=false
Rea.David
Associate II
Posted on December 01, 2017 at 03:55

On closer inspection, it appears the LSE oscillator isn't so healthy after all. Running the otherwise unmodified CubeMx project (previously attached) on our board produces a very unstable, glitchy clock. I switched to a NUCLEO-L452RE board (closest I have) with an identically-configured CubeMx build, and got the same result (measured at RCC_LSCO):

0690X000006091qQAA.png

Zooming out, there are missing clock pulses roughly every 4ms or so:

0690X000006091vQAA.png

0690X000006092FQAQ.png

Touching the oscillator causes even more erratic behavior. Breathing on either our custom board, or the NUCLEO board, causes oscillation to stop entirely; it re-starts once the area has cooled. It seems the HSE is barely at the precipice of stability. Applying a bit of cryo-spray to the LSE area of the NUCLEO board does not visibly improve stability.

To rule out a CubeMx configuration or other firmware issue, I switched to the LPTIM_PWM_LSE example from theSTM32Cube_FW_L4_V1.0 firmware package, and got the same behavior.

I was concerned our external load capacitors were too large (12pF) but the identical behavior of the oscillator on the NUCLEO board seems to at least reduce that likelihood (I would think that, out of the box, this oscillator would be properly tuned, especially given the schematic callouts of differing C31, C32 values for boards carrying L4xxR controllers). Still, for our board, with a crystal CL of 6pF, the plot of required C[Load] (Y-axis in pF) vs. C[Stray] (X-axis in pF) indicates we should probably reduce our external load caps:

AN2867 advises verifying the G[Mcrit] (oscillation loop critical gain) of the crystal. This is as follows for our crystal, the Abracon ABS07AIG-768KHZ-6-1-T:

ESR = 80KΩ

F = 32768Hz

C0 = 1.1pF

CL = 6pF

Therefore G[Mcrit] = 0.683μA/V

This satisfies the datasheet requirements (table 47) for all drive strengths except Low Drive Capability. I have tested both our custom board and the NUCLEO-L452RE board at all drive strengths with identical results.

Regardless of the C[Load] values and G[Mcrit] verification, the fact that this behavior is identical between our custom board and the NUCLEO-L452RE board makes me less-suspect of the hardware and more inclined to think this is a firmware or RCC configuration issue.

At this point, I'm stumped (for now), and short on time leading up to a customer demo. I'll switch to HSE/32 for RTCCLK for the time being, but ultimately I need to solve this to achieve battery life requirements on this product.

Thanks,

Dave

Posted on June 26, 2018 at 09:02

Hi David,

According and your calculations:

G[Mcrit] = 0.6837955692,

and as you said, en the Table 57 of the datahseet stm32l431cb, Gm(maximum critical cristal) = 0.5, 0.75 , 1.7 and 2.7 uA/V [It depends on the drive capacity, considering 2.7uA/V] and according to the AN2867, Gain Margin = Gm/

G[Mcrit]

>= 5:

Gain Margin =2.7/0.6837955692 = 3.94

So I think you are out of the margin.

Best regards.