STM32MP135 USB DFU Mode is Fussy About Cables

TommyTom · ‎2025-10-11

I know, it's probably a design flaw, but hear me out.

I'm designing a board with an STM32MP135 (in the form of a Myir Tech SoM). I have both USB1, and USB2 configured as USB-A / host mode. There is also an FTDI chip attached to UART4 for a console.

The problem that I'm having is that when I try to enter USB DFU mode (bootn = 0, 0, 0) it will only work if I connect through an OTG-style adapter to another USB-A port. The only way that I can get it to enumerate is if I connect USB2 (type A plug on the target) to a USB-C to A converter, and then to a USB-A port on the laptop. If I connect USB-A on the target to USB-C on the laptop it does not enumerate at all and if I connect via a powered HUB it gets stuck in some sort of enumeration loop.

This is the first board revision and I did not expect to need USB-OTG so those pins are floating, which I'm guessing is what I've missed, but I can't find where it mentions how they are used in the documentation. I don't have any use for USB-OTG otherwise. So my question is what is the expected setup? Why is it being fussy about cables, ports, and connectors? Would the FTDI chip be interfering somehow?

(also other features of the board work fine, and when it does enumerate properly I can flash firmware without a problem, and there does not seem to be any issue with USB host mode. So while it could certainly be poor design I'm not seeing signs of problems otherwise.)

Thanks for any advice you can offer.

PatrickF · ‎2025-10-13

Hi @TommyTom

the behavior sound normal, but it need some insight on USB behavior to understand.

My understanding is that your HW is set to use 2 x Host only port with Type-A connectors.

In that case, your application does not expose any USB OTG device in order to allows platform flashload.

Nevertheless, the HW allows to have USB OTG device connected to USB_DP2/DM2 pins

This is the setting used by the BootROM when DFU mode is used.

Issue is that USB does not allows USB device on Type-A connectors (which is only host as per standard).

The trick is to use a Type-A <-> Type-A cable to connect to a PC during DFU (such cable is not allowed as per standard, but it is ok here as only during production phase where DFU is used).

Using an (MP13) Type-A <-> Type-C (PC) does not work as (mentioned by @AScha.3 ), because the PC does not see the expected pull-downs on CC lines and so, it does not start to enumerate the device (nor supply VBUS, but here we don't care). This is required by the USB standard and any certified host with Type-C connector must follow this.

The only solution in your case should be to use either:

- a PC with Type-A connector + a Type-A <-> Type-A cable.

- a PC with Type-C connector + a Type-C to Type-A socket adapter + Type-A <-> Type-A cable. (the Type-C to Type-A adapter has internal pull-downs on CC lines)

- an USB hub with Type-A ports + a Type-A <-> Type-A cable.

Having specific setup like this is not an issue on production line.

Note that to go further on DFU for flashloading, you will need to use for 'fip-boot' a specific uBoot using USB OTG on USB_DP2/DM2 pins which will be a different uBoot that the 'fip-a/b' flashed and used on normal platform boot which will use USBH on USB_DP2/DM2 pins.

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

View solution in original post

AScha.3 · ‎2025-10-12

You show no circuit...so just guessing:

You have the 5k1 on the CC pins ? otherwise typical effect: no connection to usb-c , but to usb-A working.

If you feel a post has answered your question, please click "Accept as Solution".

TommyTom · ‎2025-10-12

Thanks for the response. Sorry I should have included more details; here are my schematics.

PatrickF · ‎2025-10-13