Using the on-chip debugging facilities (together with a debugging "pod" such as the ST-Link, and associated software) is a great tool for debugging through breakpoints, single-stepping and observing variables in memories. It also provides direct experience with the hardware, through observing and directly manipulating the individual modules' registers from "inside" the mcu.
However, this is not without consequences. The debugging module has no magical access to the individual modules; it is part of the processor itself, and uses the processor's buses to access whatever resource is attached to the processor, including memories and peripheral modules. One of the consequences of this is, that if there's some hardware which is influenced by being accessed (mainly its registers being read), it will behave differently than if it's not under debugger access.
And yes, there's quite a couple of modules which can be impacted by this. The most common related complaint is, that when debugging, UART or SPI Rx loses incoming bytes (frames). This is quite easy to understand, as these modules usually have a status bit (in the status word), indicating, that the Rx data register is not empty (RxNE). Once the debugger reads out the data register, this status bit gets cleared - thus the program (i.e. processor) - and it may happen that DMA too - will subsequently "see" a cleared RxNE thus won't proceed reading and processing the incoming data.
Most debuggers won't access registers, which are not currently displayed; and also most debuggers won't access registers if not stopped (on a breakpoint or single-stepping). However, there may be exceptions. Debugger behaviour is toolchain-specific, so for the details, read your toolchain's documentation.
- RTC lock mechanism (BYPSHAD=0) may result in old/stopped RTC registers reading