All STM32 have a built-in bootloader, which facilitates simple firmware update through one of several communication interfaces. This bootloader - which is a program residing in the "system memory" (part of FLASH, written in factory and not rewritable by users) - is started upon system reset, when certain pins or option bits are set in a certain way.

The exact combination of pins and option bits needed to start the bootloader is specific for each STM32 (sub)family and described in AN2606. This application note also contains the basic information about interfaces and pins available for bootloading (and also some other related information, such as internal resources used, or value of crystal/oscillator required for USB/CAN bootloaders, etc.). Details of communication protocols used by individual interfaces are published in separate application note for each interface.

The key information here is, that after the bootloader starts, it does not know, which interface is going to be used. Thus, it initially just "listens" for any activity on relevant pins (e.g. USART_RX pins), and if it detects such activity, it activates hardware of the given interface and starts to await the prescribed initialization sequence for the given interface.

This means, that if there is any external signal activity on any of the "listening" pins (or these pins are floating and there is enough "noise"/interference so that the bootloader "sees" activity on them), the bootloader will stop listening on the one particular interface the user intends to use. In other words, unless the user makes sure that all bootloader-related pins are at a steady level during bootloader entry, the chosen bootloader will enter unreliably or not at all.

For list of bootloader interfaces and related pins for your particular STM32, resort again to AN2606.