How to disable the USB cable detection?

[GHese.1]

Hello, I am using a STM32G473RC microcontroller and want to use usart3 to update the firmware.

I also use the CAN-BUS on pin PA11 and PA12. These pins (PA11, PA12) are also USB pins (DP and DM).

When I start the bootloader (BOOT = 1 + RESET), the "USB Cable detection" triggers and prevent communication with the USART3.

How to disable the USB cable detection?

[waclawek.jan]

You can't.

The built-in bootloader is intended to be used in "quiet" environment, i.e. with all pins which would trigger a different bootloader, disconnected or at steady "harmless" levels.

Workaround is to use your own bootloader.

JW

[waclawek.jan]

On second thought...

> "USB Cable detection" triggers

Why do you think so?

AFAIK there is no "USB cable detection" (as in VBUS detection - I know AN2606 calls the USB bootloader detection this way) implemented in the bootloader, so if you are sure it's the USB bootloader which gets activated, it would work on the Reset condition on USB bus. And that would be strange, as that would imply that both DP and DM is pulled down, while DP is pulled up by the internal 1k5 pullup - but as DP is CAN_Tx, there should be nothing pulling it down significantly enough.

JW

[GHese.1]

Whether the USB cable detection triggers depends on the isolator used.

With an Is8622BC it works fine, with ADUM1281ARZ it doesn't work.

It sounds ridiculous but with a resistor between the CAN1Rx (USB-DM) and CAN1Tx (USB-DP) it works fine with both, Is8622BC and ADUM1281ARZ.

I have reworked 10 PCBs, all working fine.

[waclawek.jan]

Again, why do you think your problem is namely "USB cable detection"?

JW

[GHese.1]

None of the PCB's communicate through Usart3 in boot mode. I send 0x7F, there is no response.

Until you desolder U5, R33 and R34 (connected to CAN/USB port)

[AVill.5]

Hello, sorry to reopen this question.

I have the same problem with a STM32G0B1 (100lqfp pin version). We also have a processor connected to spi2 port to upgrade the STM32. Sometimes the micro is not responding to sync attempts on the spi2 port. We arrived at the same point mentioned by GHese.1 about "USB cable detection", because it is impossible for other interfaces to be triggered by a cable event or something like this according to par 44.2 of AN2606.

In our application, we don't need USB port. We use PA11 (as comparator output) directly routed to PE3 (as input) and PA12 is left floating.

What is the safe condition for USB port to avoid to be triggered by bootloader port polling loop (as AN2606 describes, the usb port is the last interface, and the only one which does not consider bytes to enter in programming mode)?

Is there a safe way to set the pins externally via pullup or pulldown to avoid false activation of the usb port during the ST system bootloader update phase? We tried to pull-down DM and pullup (or floating) DP. Is this the correct and safe way to prevent false USB detections?

We prefer to keep the original ST system bootloader for the firmware upgrade phase instead of writing a custom bootloader. In my honest opinion, ST should better describe the pin state of each interface during the boot phase. We have a lot of products with this problem and production was stopped due to it. Thanks for your support

AV

[nino]

Hi, same here with the STM32G491. We see the issue on not every board but about one out of ten.

We prepared a proper USB interface but on some boards we needed to introduce pull resistors for the D+ and D- lines (1 M pull resistors, pull-up for USB_DP and pull-down for USB_DM).

Referring to AN2606, how exactly is the "USB Cable Detected" work in the flow diagram (AN2606, rev. 60, page 243)? What does the peripheral block need to see/experience to decide it has detected a USB cable?

Our understanding so far is that the USB_DM line is in a very high impedance state and really floating (changing voltage level) such that the peripheral starts to detect a state change of the USB data lines. However, this can not be measured as even our active probes have 1 M input impedance and thus the issue is gone as soon as we try to measure the data lines. Also, we have experienced that the issue resolves when plugging in a USB cable (only the cable, no host on the other end). We assume that the cable introduces enough capacity to stabilize the USB signals.

We will introduce the pull resistors to our product as a best-effort fix but we'd really like to understand the issue in more detail. We have never seen any USB peripheral requiring pull resistors for the USB data lines. 

Thank you and best regards

[waclawek.jan]

@GHese.1, @AVill.5 , @nino ,

I'm still not convinced, that the bootloader indeed enters the USB DFU branch.

Correct me if I'm wrong: evidence above is that:

- sometimes the intended bootloader (UART?) is inoperative, even if it's certain that bootloader was entered

- modifying PA11/PA12 circuitry appears to decrease dramatically the possiblity of this failure; in two cases it appears that pulling down DM did the trick, in description of original problem it was removal of pullups

And that is why I don't think it's the USB bootloader. There is no cable detection (no VBUS pin used), so there's no other way to "detect connection" than to detect it on DM/DP. Normally, when hub is connected, DM is pulled low by the hub's pulldowns; so if something pulls DM up in the non-connected state, that is clearly a signal to the USB machine that there is no hub present, so no communication.

Now, the bootloader is in open ROM and can still be normally debugged, even if we don't have the sources to it. I would be very happy if somebody would try to connect a debugger, enter the bootloader, get it into the non-responding-on-expected-bootloader-interface, stop execution and capture stack/RAM/processor registers content. That, together with content of the boot ROM should be enough to decipher, what's going on.

Of course this is simpler to do for ST, but I wouldn't hold my breath.

JW