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):
Zooming out, there are missing clock pulses roughly every 4ms or so:
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
