The way I read the errata sheet, you can't even use PC13 for calibration, as (ironically) the signal you use in the calibration process may disturb the very clock you want to calibrate.
Basically, yes. Errata are all about blunders like these.
In many STM32 there are secondary RTC outputs, outside of the low-power backup/VBAT-power-domain, where you can redirect the calibration output (they sometimes have associated errata, too, but of different nature). Not in 'F411, though.
Another way to calibrate, somewhat indirectly, is to use the LSE-to-TIM5 connection to compare the LSE to a known good time source. Another option is to output LSE onto MCO and measure there.
During the weekend, I was playing with a Nucleo-F411. It has (in the version I have, which I believe is the second one, I don't have it at hand and I plan to write a longer writeup on that experiment when time allows) an on-board through-hole 32.768kHz crystal and the ground arrangement of the burden capacitors which is IMO less than optimal. Running experiments only with the LSE and PC13 (i.e. no other internal modules active, nor any other pins toggling, nor any external circuitry being active (not that there is any at the Nucleo, just wanted to stress the "quietness" of the environment)) I found out, that outputting the 512Hz calibration onto PC13 did cause increased jitter at the LSE output (as monitored through MCO), but it did not change the LSE frequency (as monitored through said TIM5, comparing to HSE fed from the STLink's MCO which has a 8MHz crystal as primary source), or at least not significantly enough so that I would observe it (short-term it stayed within 1ppm). Increasing the LSE drive to high significantly decreased that jitter, too.
I have also toggled PC13 as a GPIO output, and also set it to input and toggled it from a different pin. In both these cases the toggling was asynchronous to LSE, and it caused not only jitter on LSE, but also a changing frequency, again in short term (1s) up to +-5ppm.
What I am getting at is, that while the issue outlined in the erratum is certainly there, its severity will surely depend on the particular design of the LSE circuitry and the nature of the signal at PC13. As the frequency difference observed by OP is far far more dramatic than a few ppm, I bet that either the LSE design is such that its stability is poor even without the signal at PC13, or it's what @Peter BENSCH hinted above, that LSI is used instead of LSE as RTC clock.
Clicking in CubeMX alone sometimes does not lead to functional results. In this particular case, for example, if LSI was ever selected as RTC clock and there was no backup-domain reset of either form, then it does not matter that subsequent code is written so that it would use LSE, LSI remains to be the RTC clock source. Debugging should always start with reading out and checking the relevant registers (here, RCC_BDCR, and possibly RTC registers).
JW
