Factory programming an STM32MP157 via USB-C

[rtie]

If I have grasped USB-C correctly, the BootROM must communicate with the STUSB1600 chip for role negotiation, otherwise it couldn't switch to device mode and thus it wouldn't be possible to use serial boot mode over USB-C. On the DK2, the STUSB1600 is connected to I2C4, and quite obviously, serial boot mode works on that hardware.

Since I was unable to find any information on these details:

1. Does the boot ROM communicate with the STUSB1600?
2a. If it does, is it hard-coded to I2C4 or is it possible to use a different I2C?
2b. If it doesn't, how/why does role selection work without proper negotiation?

In other words: is it possible to send the TF-A bootloader to an STM32MP157 via USB-C if the STUSB1600 chip is connected to a different I2C bus than I2C4?

Best regards,
Robert

[PatrickF]

Hi @rtie 

BootROM does not communicate with any outside components (except the Flash itself, and in DFU mode, the USB and the UART). Even not with STPMIC. That's intended to make BootROM as agnostic as possible from external components.

Are the CC1DB and CC2DB connected as on STM32MP157F-DK2 ?

Did you try using a Type-C to Type-A cable ? Type-A is maybe required to have the Host (PC) to be a DFP (which is btw the only possible mode for Type-A).

Not sure the STUSB1600 have then 5.1k pull-down (Rd) enabled by default (need to check spec), as this is required by other side to detect the UFP in case of Type-C <-> Type-C cable.

 

During factory programming, it is usually not a concern to use specific cables.

 

Regards.

 

[rtie]

We are still planning and stumbled across this detail. Looks like the 5.1k pull-downs are indeed enabled by default ("dead-battery mode"), so it should work, I guess. After thinking a bit more, however, it seems better to use pure USB-2.0-OTG/UFP mode in our case. Easier and cheaper. We'll discuss this a little internally.

Thank you very much for your reply!