Boot Sequence Quiescence

[Aron Phillips]

Posted on December 06, 2017 at 20:28

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 (

https://github.com/Ell-i/ELL-i-PyBot-Tests/wiki/Programming-from-Linux-(via-DFU)

 ) 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.

[Tesla DeLorean]

Posted on December 06, 2017 at 21:43

The supported USART RX pins are connected to timer inputs in order to measure the 0x7F (8E1) pattern. You really don't want noise on these pins. We've typically used pins carefully, and attached them to serial ports that are not naturally banging up and down when started. ie USART3 connecting to a MAX3232. Once the pulse is measured it is used to configure the USART to the appropriate baud rate and respond.

The connectivity test is one-shot in nature, so if a reset and retry is required don't make it overly difficult to achieve. For CAN/USB make sure your external clock starts promptly and stably.

[Tesla DeLorean]

Posted on December 06, 2017 at 21:56

Also, you're not compelled to use the System Loader, if you understand your board and pin utilization you can write your own loader, and have it behave however you want.

The System Loader is designed to ease production programming where you have things under a bed of nails or some level of control, or when the end user entirely bricks the device and breaks your loader and the features and security you've engineered into that.