STM32MP135D factory programming testing using STM32MP135F-DK

[mmichala]

Hello,
we are developing IoT device for which we are planning to use STM32MP135D MPU placed on our custom SoM.
To do test before SoM is ready, I have obtained a STM32MP135F-DK. There are some concerns about the 'factory programming' of such device.
With the STM32MP135F-DK the method I have tried is to set all Boot switches (BOOT0, BOOT1, BOOT2 pins) to 0. Then the device boots into "Force USB boot for programming" mode, and the firmware can be uploaded using STM32 Programmer CLI running on PC. It works fine.
As pic. 1 shows, also USART3 can be used for factory programming and that was the plan for SoM. Of course first I wanted to try it with DK. But unfortunately, the default USART3 TX and RX pins aren't accessible at STM32MP135F-DK GPIO connector. After research I came to conclusion that also USART6, UART4, UART5, UART7, UART8 are not accessible at that STM32MP135F-DK.

1. Is my conlusion right? Can I somehow test factory programming using USART instead of USB with STM32MP135F-DK?
2. Maybe we can also tried using USB for factory programming with our SoM. What pins are needed for that? I found that USBH_HS_DP2(boot) and USBH_HS_DM2(boot) are used, but any other? What is the role of this STM32G071G8U6N when it comes to USB factory programming (pic. 2)
3. Is the a possibility to achive factory programming using SWD?

[PatrickF · Accepted solution]

Hi @mmichala 

programming a complete Linux package (hundreds of MBytes) with UART would be extremely slow, except if you have very tiny bare-metal application.

We recommend using USB OTG, as you already see, only 2 pins are needed by BootROM for STM32MP13x side (USBH_HS_DP2 and USBH_HS_DM2).

STM32G0 you see on STM32MP135F-DK is to manage USB Power Delivery and Dual Role Data. It is not required for USB device required for flashload.

If you use USB Type-C, only two 5.1k pull-down on CC1 and CC2 is needed to allow detection as a device. VBUS could be left open.

Please also refer to AN5474