Bootloading

From Wiki at Neela Nurseries
Revision as of 07:31, 1 September 2022 by Ted (talk | contribs) (^ STMicro bootloaders)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

2022-08-01 Notes on bootloaders for microcontrollers

Keywords: bootloader :: bootloaders :: serial bootloader :: serial bootloading


A starting point, which links to five articles on differing bootloading approaches:


2022-08-03

What is a serial bootloader and how is it used?

Following link gives Silabs example, but is not a good general explanation:


^ Atmel bootloader


^ STMicro bootloaders

Serial bootloading on STMicro MCUs, or title of application note AN3155 "USART protocol used in the STM32 bootloader":

Following is an interesting link in that it appears to cause web browser to download the linked pdf file, and then subsequent visits to this link redirect to the local downloaded copy:


QUESTION: How to enter bootloader? activate bootloader for STM32 parts?

ANSWER: In a general sense STM32 bootloader activation depends often on both certain config register bits settings and also one or two pin states at power up. For the STM32WL55, document AN2606 pages 28 and 370 give us a starting point for the names of the configuration registers in which to set or clear certain bits, and the name of the pin, BOOT0, to hold high or low at power up. Each MCU family or line has variations on this theme . . .


With the STM32WL55xx Nucleo board, STMicro's AN2606 application notes document says that USART1 is enabled with RX and TX lines assigned to PA10 and PA9 respectively. These MCU pins map to connectors and connector pins:

USART1 TX --> PA9  . . . CN5 pin 2
USART1 RX --> PA10 . . . CN8 pin 3
              GND  . . . CN5 pin 7 and others

2022-08-30 TUE - Looking for how to enable USART1 on STM32WL55JC. Strange, we see in [our+app]/build/zephyr/zephyr.dts a reference to:

179                         lpuart1_tx_pa2: lpuart1_tx_pa2 {
180                                 pinmux = < 0x48 >;
181                                 bias-pull-up;
182                                 phandle = < 0x4 >;
183                         };

. . . which is one of the pins called out in the board level device tree file [zephyr_3p1p0_root]/boards/arm/nucleo_wl55jc.dts, for lpuart1 device node. We want to enable &usart1, and it looks like we'll want to specify RX and TX pins similarly. But where and how is 'lpuart1_tx_pa2' defined?

While our question here is not fully answered a chance wildcarding of grep search pattern yields a result which may help. Note 'usart2_tx_pa2' pattern in second to last result:

./zephyr-nucleo-wl55jc2/build/zephyr/dev_handles.c:95: *   - (/soc/pin-controller@48000000/lpuart1_tx_pa2)
./zephyr-nucleo-wl55jc2/build/zephyr/zephyr.dts.pre:1328:   /omit-if-no-ref/ lpuart1_tx_pa2: lpuart1_tx_pa2 {
./zephyr-nucleo-wl55jc2/build/zephyr/zephyr.dts.pre:1353:   /omit-if-no-ref/ usart2_tx_pa2: usart2_tx_pa2 {
./zephyr-nucleo-wl55jc2/build/zephyr/zephyr.dts.pre:1511: pinctrl-0 = <&lpuart1_tx_pa2 &lpuart1_rx_pa3>;

ted@localhost:~/projects-sandbox/workspace-for-nucleo-wl55jc2$ grep -nr 'tx.*pa2' ./*

Ok the "omit if no ref" key words or key phrase in device tree must be a qualifier of a defining line, not a test to see whether a node has already been defined:

$ grep -nr usart1_tx_p ./* | grep wl55 | grep usart1_tx_p
./modules/hal/stm32/dts/st/wl/stm32wl55ccux-pinctrl.dtsi:544:			/omit-if-no-ref/ usart1_tx_pa9: usart1_tx_pa9 {
./modules/hal/stm32/dts/st/wl/stm32wl55ccux-pinctrl.dtsi:549:			/omit-if-no-ref/ usart1_tx_pb6: usart1_tx_pb6 {
./modules/hal/stm32/dts/st/wl/stm32wl55jcix-pinctrl.dtsi:781:			/omit-if-no-ref/ usart1_tx_pa9: usart1_tx_pa9 {
./modules/hal/stm32/dts/st/wl/stm32wl55jcix-pinctrl.dtsi:786:			/omit-if-no-ref/ usart1_tx_pb6: usart1_tx_pb6 {
./zephyr/tests/drivers/uart/uart_async_api/boards/nucleo_wl55jc.overlay:11:	pinctrl-0 = <&usart1_tx_pb6 &usart1_rx_pb7>;
./zephyr-nucleo-wl55jc2/build/zephyr/zephyr.dts.pre:1333:   /omit-if-no-ref/ usart1_tx_pa9: usart1_tx_pa9 {
./zephyr-nucleo-wl55jc2/build/zephyr/zephyr.dts.pre:1338:   /omit-if-no-ref/ usart1_tx_pb6: usart1_tx_pb6 {


2022-08-31 WED

Talking to STM32WL55 stage one bootloader via UART:

(serial-work) ted@localhost:~/projects/python/serial-work$ python3 serial-test.py 
Script starting,
At loop to attempt bootloader handshake several times:
b'\xff'
b'y'
b'\xff'
b'y'
constructed bootloader command  b'\x00\xff'
sending b'\x00\xff' to bootloader . . .
b'y'
b'\x0c'
b'3'
b'\x00'
b'\x01'
b'\x02'
b'\x11'
b'!'
b'1'
b'D'
b'c'
b's'
b'\x82'
b'\x92'
b'\xa1'
b'y'

script done.

These commands 0x00, 0x01, 0x02, 0x11 and the others through 0xA1 are the same commands listed in ST application note an3155-usart-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf on pages 9 and 10. The lower case 'y' has ASCII value 0x79 which is STMicro's bootloader ACK or acknowledge byte. These results show we are talking with the bootloader.

So far for some reason only baud rates 115200 and 230400 succeed. Slower baud rates fail with no response from the MCU to the host.


^ RP2040 bootloaders


^ References