STM32 gotchas
172. UART receives zeros? Using pullup with UART_Rx may be a good idea (not STM32-specific)

The pin set for UART_Rx is effectively a high-impedance input, and it relies on the connected transmitter to provide the correct idle (usually high) voltage level when there are no frames transmitted. However, this may be not always the case - the transmitter may go into high-Z, e.g. if it is a second microcontroller and it is being reset, or it has a bug in its firmware. In some designs, the transmitter can be physically disconnected (e.g. behind a connector); in others, removing power supply or external (e.g. USB) connectivity from transmitter may leave the connection be floating.

In such cases, the floating line may either drift to zero, generating a surprising BREAK frame (which in STM32 UART is received as 0x00 together with Framing Error), or the UART may receive spurious characters through coupling to neighbouring signal lines. While software ought to be written in such a way that such events won't cause major problems (e.g. UART data might be packetized/checksummed, timeouts may be implemented, received data sanity may be tesed, error flags should be meticulously handled, etc.); it is always better to have also the baseline data as error free as possible.

Perhaps the simplest way to ensure a fairly secure input level in case of potentially floating UART_Rx is to use the humble pullup. It may be an external pullup of any appropriate value, but in most cases it's enough to switch on the internal pullup. In contrast to external pullup, it costs nothing (it came "bundled" with the mcu), and its nominally 40kΩ value is appropriate in most practical cases. There may be implications in mixed-voltage systems, though, as pullups shouldn't be switched on with 5V input signals even if the given STM32 pin is 5V tolerant.

Of course, this solution is not applicable in severely power-constrained designs. The internal pullup increases total power consumption by cca 100μA when the transmitter pulls the line down; if the communication is sparse (which is often the case), the average power consumption is proportionally lower.