In order to present the software with a consistent set of the timekeeping registers (RTC_SSR, RTC_TR, RTC_DR), the RTC (except the 'F1 family, which has a significantly simpler RTC) implements a mechanism,
where reading subseconds from RTC_SSR or time from RTC_TR will lock all three registers the "higher rank" registers, until date is read from RTC_DR.
The "true" timekeeping registers will continue running, only the readout interface towards APB/processor is locked.
Depending on the particular order in which a debugger reads out the RTC registers, the lock mechanism may also influence the way how the RTC timekeeping registers are presented in debuggers - they may display an old value, or inconsistent values.
The lock mechanism results in the most common RTC-related complaint - an unaware user may want to read only the time from RTC_TR, but once he reads RTC_SSR (e.g. because that's what a time-reading "library" function does), RTC_TR readout stops changing, making the impression of a stopped RTC.
While it's easy enough to avoid this "problem" by reading RTC_DR after each reading of RTC_TR, the RTC has an option to suppress this mechanism, by setting RTC_CR.BYPSHAD=1. Then, it's upon the user to ensure registers' consistency (the RM recommends to read all registers twice, and repeat if they don't match).
Sadly enough, the RTC locking mechanism does not work properly in most STM32s (this appeared in errata of all STM32s starting appearing there by the end of 2016, so some newer STM32s may have this fixed, check your STM32's errata). This means, that for consistency, the three registers have to be read out twice and compared, regardless of RTC_CR.BYPSHAD setting. There may be a difference in timing of the read with different setting of RTC_CR.BYPSHAD, though.