We need to know if, according to AN2606, STM processors require the other boot methods to be quiescent (inactive or dormant) in order not to lock up the system.
To explain this issue, on another STM processor in the past (STM32F405), we tried to put the device in DFU mode but we could not get any further until we put pull-up resistors on the RX and RD pins of the available boot buses via information we have found on the internet (Programming from Linux (via DFU) · Ell-i/ELL-i-PyBot-Tests Wiki · GitHub ) a note which states
Put the board in DFU mode. To do this, you need to make BOOT0 high, and BOOT1 low, and reset the board. Since the onboard bootloader supports bootloading over UARTs, CAN bus, and USB, you need to make sure that UART1 (PA9/PA10) UART3 (PB10/11 and PC10/11) and CAN (PB5/13) are quiescent while bootloading.
This seemed to have worked. We were finally able to get the buses "inactive" by preventing the system thinking it received data by keeping the receive pins from sending data. We assumed the receive pins were floating extreme enough to make the processor think there was data.
Is this actually still an issue today? None of the development boards have any pull resistors on the bus pins. We would like a definitive answer as to what should be done with the boot buses.