STM32MP157C-DK2 Uart Boot

[ANiko.3]

Is it possible to boot over UART on the STM32MP157C-DK2?

I set the BOOT pins as following:

BOOT0 - OFF

BOOT1 - OFF

I am using the FT232 UART-USB Adapter and have connected the following pins:

• UART GND - CN16 GND
• UART VCC - CN16 3.3V
• UART TX - CN14 ARD_D1
• UART RX - CN14 ARD_D0

​

Here is the CubeProgrammer command and its output:

´´´

$ STM32_Programmer_CLI -c port=/dev/ttyUSB0

     -------------------------------------------------------------------

                       STM32CubeProgrammer v2.5.0                 

     -------------------------------------------------------------------

Serial Port /dev/ttyUSB0 is successfully opened.

Port configuration: parity = even, baudrate = 115200, data-bit = 8,

                    stop-bit = 1,0, flow-control = off

Timeout error occured while waiting for acknowledgement.

Timeout error occured while waiting for acknowledgement.

Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again...

´´´​

Am I doing something wrong?

Regards,

Aleksandar

[PatrickF]

The chosen pin should be in the short list of UART pins available for boot. Those used here are not in this list.

See pin list on https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#UART_Boot

Btw, DK2 could directly be used in UART boot on UART4 when using USB cable connected on STLINK port (CN11).

Note that currently 'single' UART boot is limited to load TF-A then uBoot only. No flashing is currently possible (need some uBoot changes to avoid conflict with uBoot Console). Stay tuned for a new ecosystem release soon.

[ANiko.3]

Hello Patrick,

thanks for the answer. I have changed to the following pins (GPIO expansion connector).

• UART GND - CN2 PIN 6
• UART VCC - CN2 PIN 1
• UART TX - CN2 PIN 10 GPIO15 / USART3_RX (On STM its PB12)
• UART RX - CN2 PIN 8 GPIO14 / USART3_TX (On STM its PB10)

According to the link you sent me, the pins PB12 and PB10 should be available for serial boot (USART3). However, the output from the CubeProgrammer is the same. Any thoughts?

[PatrickF]

That's should be ok.

With only USB supply and USART3 connected (USB device not connected), you should have LD6 red led blinking fast.

Then red led should stop blinking when CubeProgrammer connect to the DK2.

Check you are using the right /dev/tty port.

[ANiko.3]

Hi Patrick,

No USB device connected, just USART3 and the USB supply. The LED6 is blinking but also LED4 (with lower frequency than LED6).

I am using the right /dev/tty port (here the output of CubeProgrammer).

$ STM32_Programmer_CLI -l uart

     -------------------------------------------------------------------

                       STM32CubeProgrammer v2.5.0                 

     -------------------------------------------------------------------

===== UART Interface =====

Total number of serial ports available: 1

Port: ttyUSB0

Location: /dev/ttyUSB0

Description: FT232R USB UART

Manufacturer: FTDI

However the error is still there.

[PatrickF]

Maybe add a pull-up on USART3_TX (e.g. 10K). Until the BootROM detected the right activity on USART3_RX, the related TX is open, and this floating signal might create wrong detection of first character on your FTDI interface.

Another debug step is then to check the activity on the pins.

[ANiko.3]

The CubeProgrammer is sending out the correct data (0x7F), however no response from the CPU. Also when the board is booting from the SD card (it boots successfully), there is no boot output on USART3. Is it okay or I should see the boot output?

Regards

[PatrickF]

Hi,

in SD-Card boot, there is nothing expected on USART3.

In your trials using USART3, did you see LD6 red led stop toggling ?

After the fail, without resetting the board, could you try to use (need OpenSTLinux v2.0.0 SDK), with ST-Link connected (need to be connected before the trials to avoid unwanted board reset)

PC$ ./openocd -f board/stm32mp15x_dk2.cfg -c 'init;cortex_a smp off;halt;dump_image traces.bin 0x2ffc1c00 2048;resume;shutdown'

and analyze the trace.bin generated using https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_trace_analyzer

Regards,

Patrick

[ANiko.3]

Hello Patrick,

I have used the following setup for the ROM trace:

• power supply, 4 USART pins (used for the serial boot) and ST-Link (used for the ROM trace)
• ​Additionally, the LD6 is blinking red (no changes), LD4 is red and ON.

​

Here is the first command (STM32CubeProgrammer):

´´´

PC$ STM32_Programmer_CLI -c port=/dev/ttyUSB0

-------------------------------------------------------------------

STM32CubeProgrammer v2.5.0

-------------------------------------------------------------------

​

Serial Port /dev/ttyUSB0 is successfully opened.

Port configuration: parity = even, baudrate = 115200, data-bit = 8,

stop-bit = 1,0, flow-control = off

​

Timeout error occured while waiting for acknowledgement.

​

Timeout error occured while waiting for acknowledgement.

Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again...

´´´​

​And here is the ROM trace.

´´´

PC$ python3 rom-trace-analyzer.py traces.bin

< @ 00007461 | [INFO] - BOOTCORE_BootRomMaskVer ( 0x00000000 ) >

< @ 00008741 | [INFO] - BOOTCORE_BootRomVer ( 0x0000020E ) >

< @ 00009910 | [INFO] - BOOTCORE_FreezeIWDG12Clocks >

< @ 00011322 | [INFO] - BOOTCORE_HwResetPOR >

< @ 00022772 | [INFO] - BOOTCORE_ChipModeSecOpen >

< @ 00025143 | [INFO] - BOOTCORE_LogicalResetSystem >

< @ 00026910 | [INFO] - BOOTCORE_BootActionColdBootProcess >

< @ 00084001 | [INFO] - BOOTCORE_BootCfgOtpWordValue ( 0x00000000, 0x00000000 ) >

< @ 00085445 | [INFO] - BOOTCORE_BootPinsFirstSelSerial >

< @ 00086529 | [INFO] - BOOTCORE_OtpPrimarySrcForceNothing >

< @ 00087594 | [INFO] - BOOTCORE_OtpSecondarySrcForceNothing >

< @ 00088566 | [INFO] - BOOTCORE_BootPinsOverridesOtp ( 0x00000001 ) >

< @ 00089791 | [INFO] - BOOTCORE_OtpBootSrcDisableMaskVal ( 0x00000000 ) >

< @ 00090922 | [INFO] - BOOTCORE_OtpBootUartInstanceDisableMaskVal ( 0x00000000 ) >

< @ 00093245 | [INFO] - BOOTCORE_BootCfgAfmuxOtpWord1Value ( 0x00000000 ) >

< @ 00094603 | [INFO] - BOOTCORE_BootCfgAfmuxOtpWord2Value ( 0x00000000 ) >

< @ 00096023 | [INFO] - BOOTCORE_BootCfgAfmuxOtpWord3Value ( 0x00000000 ) >

< @ 00097513 | [INFO] - BOOTCORE_BootCfgHseValue ( 0x00000000 ) >

< @ 00100490 | [INFO] - BOOTCORE_EnabledSrcMaskVal ( 0x00000640 ) >

< @ 00101845 | [INFO] - BOOTCORE_BootModeNOBOOTCSTANDBY >

< @ 00640349 | [INFO] - BOOTCORE_StartupWaitTime ( 0x00002700 ) >

< @ 00641914 | [INFO] - BOOTCORE_ReOpenDebugValue ( 0x00000000 ) >

< @ 00644147 | [INFO] - BOOTCORE_Pll12StartNotDisabledByOtpBit >

< @ 00646177 | [INFO] - BOOTCORE_Pll1Started >

< @ 00650163 | [INFO] - BOOTCORE_Pll1Locked >

< @ 00651537 | [INFO] - BOOTCORE_Pll2Started >

< @ 00656089 | [INFO] - BOOTCORE_Pll2Locked >

< @ 00657674 | [INFO] - BOOTCORE_CkMpuSsSwitchedOnPll1 >

< @ 00659154 | [INFO] - BOOTCORE_CkAxiSsSwitchedOnPll2 >

< @ 00659735 | [INFO] - BOOTCORE_Pll12StartReqStatusPllStarted >

< @ 00674539 | [INFO] - BOOTCORE_HseDigBypassDetected >

< @ 00679998 | [INFO] - BOOTCORE_HseFrequencyDetected ( 0x00000018 ) >

< @ 00680419 | [INFO] - USB_Init >

< @ 00750893 | [INFO] - BOOTCORE_PllUsbLocked >

< @ 04342328 | [INFO] - UART_PeripheralSerialBootLoopStart >

´´´

​

The weird thing I found is the last output, UART_PeripheralSerialBootLoopStart, it seems as the serial boot has started but cannot connect to the UART?

​

PS:

• If I connect over ST-Link (for both serial boot and ROM trace), sometimes the CubeProgrammer can connect to the CPU, sometimes no. In case it cannot, the ROM trace is the same as above. In case it can, the ROM trace has the additional line:
  • < @ 48705400 | [INFO] - UART_Selection ( 0x00000004 ) >
• If I connect over OTG (the other USB type C), the STM32CubeProgrammer can recognize the CPU. The ROM trace in this case has the additional line:
  • < @ 16662251 | [INFO] - USB_Loop >

Regards

[PatrickF]

Hi,

• < @ 16662251 | [INFO] - USB_Loop >

is present because of enumeration of USB DFU port (when you plan to use CubeProgrammer on the usbX).

• < @ 48705400 | [INFO] - UART_Selection ( 0x00000004 ) >

is present because UART4 is used by ST-Link when you use CubeProgrammer on the ST-Link related /dev/ttyXXX.

LD6 should stop blinking.

It should work similarly with other UARTs, and so for USART3 PB10/PB12 pins. Did you check adding a pull-up on USART3_TX line ?

Regards.

[ANiko.3]

Hi Patrick,

I havent added a pull-up, Ill do it today and check the results. So basically the ROM cannot detect that USART3 TX is activated? And adding a pull-up on it could fix i?

Regards

[PatrickF]

This is not related to the ROM, but rather on your UART<->USB cable behavior in case TX is Hi-Z.

In order to avoid any interaction on user board, each UART_TX are kept Hi-Z until the 0x7F is received on one valid RX pin. Then the related TX is enabled (i.e. driven high) and the ROM send acknowledge. Your cable might detect the transition from Hi-Z to high as a character (or an end of 'break' state) and might not correctly manage the first data.

But even without pull-up, you should see some activity on the TX line if you put an analyzer/oscilloscope. Are you sure of your cable wirings (signals and power) ?

[ANiko.3]

The wiring is okay, Ive checked it many times. I measured the data on the TX Pin (CN2 PIN 10 GPIO15), the 0x7F is detected, but no activity on the RX pin (CN2 PIN 8 GPIO14). Ill measure everything today again (with and without the pull-up) and write the results here.

Regards

[ANiko.3]

Hi Patrick,

we have changed the USB-UART Adapter and it should work soon. However, I am still wondering about the flashing. You mentioned we cannot flash over UART at the moment and we need some uBoot changes to avoid conflict with uBoot Console. Could you point me to someone who could help me with the necessary changes in U-Boot?

Regards

[Olivier GALLIEN]

Hi @Community member​ 

Please give it a try with a freshly release DV2.1 (see wiki) , taking care to enable usart3 in Uboot DT ( disabled by default)

Olivier