USB cable detection in bootloader, VBUS or DP/DM?

[Mike Ciholas]

App note AN2606 on bootloader operation, figure 57, shows the flow chart for the STM32H74/75 series. One block is labeled "USB cable Detected". Exactly what is the criteria for this? Is it based on DP/DM states? Is it based on VBUS measurement? Something else?

I have a design that is IO heavy and would like to use the VBUS pin for other purposes than sensing USB voltage. If I don't hook up VBUS to the USB connector, does the bootloader still detect the USB cable and enter the bootloader? Or does it depend on the VBUS for cable sensing?

If it does depend on VBUS for cable sensing, the cable might be just a power supply (phone charger, say) and the bootloader would get stuck listening to nothing instead of continuing to search among the various other options (UART, SPI, I2C, CAN, etc). So I'm hopeful VBUS sensing is not the criteria.

I don't need OTG functions, just simple USB FS device, so I am trying to use just DP/DM on the USB port.

Thanks.

[waclawek.jan]

AN2606 documents, which resources (including pins) does the bootloader use. Is VBUS pin mentioned for given STM32 model?

JW

[Mike Ciholas]

AN2606 only mentions DP/DM signals (pins PA11, PA12). It does not mention VBUS (pin PA9) at all. Is the lack of VBUS mention in AN2606 enough to be SURE that VBUS is not used? AN2606 has been known to not quite jibe with the DS/RM for the chips it references, so I find it hard to rely on it absolutely.

If VBUS is not used that still leaves the question of exactly how the USB cable is detected, via DP/DM pull up/downs?

[Tesla DeLorean]

Nuances of how the internal loader works can either be gained through discussions with FAE's or inspection of the code. I tend to prefer the latter as it is more definitive. You could roll the dice with an Online Support Request and see what FAQ information comes out of the internal database.

The DP is usually pulled high internally, so I'd assume it's is using that as a detection method. USB not really an area of interest for me.

AN2606 diagrams a VBUS to DP pull-up method for STM32 without the internal pull-up

[Mike Ciholas]

The only truly definitive answer is to disconnect VBUS on an eval board, ground it to be sure it is not indicating voltage, and see if the part can still enter the bootloader. This is perhaps the fastest and least uncertain of all methods to figure out what is required.

Well, this test is definitive until the bootloader version is changed and then it could fail again depending on what was changed.

[waclawek.jan]

> Is the lack of VBUS mention in AN2606 enough to be SURE that VBUS is not used?

Yes.

(Legalese: note that I am not ST).

It's also easy to try - get a Nucleo, disconnect its VBUS, try.

> If VBUS is not used that still leaves the question of exactly how the USB cable is detected, via DP/DM pull up/downs?

USB set to device by bootloader pulls up DP to indicate a full-speed device to attached host. Per 9.1.2 Bus Enumeration in USB2.0, host upon detecting connection initiates a Reset condition (single-ended 0 for >= 10ms), that is detected in the USB module of STM32, see OTG chapter in RM, OTG_GINTSTS.USBRST, and also the Device Initialization subchapter.

> AN2606 has been known to not quite jibe with the DS/RM for the chips it references

Can you be specific, please?

That AN2606 leaves open questions is another thing, but I don't know of any outright conflict with DS/RM.

JW

[rammit]

How does the chip detect a USB cable? Is it just looking for a simple high or low state on boot or is it looking for a packet? The USB spec seems to inidcate it just looks at DP and DM (7.1.7.3)

"A connect condition will be detected when the hub detects that one of the data lines is pulled above its VIH

threshold for more than TDCNN (see Figure 7-27 and Figure 7-28)."

[Grant Bt]

I don't know. That sounds to me like the conditions for the hub to detect a device.

[Mike Ciholas]

JW write:

>> AN2606 has been known to not quite jibe with the DS/RM for the chips it references

 >

> Can you be specific, please?

Sure, case in point:

STM32G070 uses pattern 11. In AN2606, the pattern talks about BOOT_EP and USE_BOOT0_OPT bits. In the RM, those bits don't exist and it mentions nBOOT_SEL bit, which aren't mentioned in AN2606. So how to map BOOT_EP and BOOT0_OPT to nBOOT_SEL?

That's confusing and inconsistent, hence my concern that AN2606 is not a document of highest trustworthiness if it can't get bit names consistent.

In other words, the simple fact VBUS is not mentioned in AN2606 is not enough for me to have confidence it isn't required. Part of that lack of confidence is prior inconsistencies in AN2606.

[waclawek.jan]

Ah those... :)

Point taken.

Posted a request.

> In other words, the simple fact VBUS is not mentioned in AN2606 is not enough for me to have confidence it isn't required.

Please note that this is a primarily user-driven forum with casual ST presence. If you need assurances, you have to go to ST directly, through web support form or through FAE.

JW

[Mike Ciholas]

JW wrote:

> Please note that this is a primarily user-driven forum with casual ST presence.

Nothing beats actual experience, and that's what users have.

I ask questions here not to have someone read me the docs, I can do that myself, and that's what tech support does mostly, but I ask to see if someone has actual experience with the issue.

The net result is that I will experiment with VBUS and then report the results. I expect VBUS is not required for bootloader operation, but would like to confirm since that affects my pin muxing plan.

[waclawek.jan]

> Will the chip go into the USB boot loader if it detects a certain pin state (or single toggle) on DM (PA11) and DP (PA12) or does it require a more complicated transaction?

I don't know. I would expect that bootloader first tests HSE presence, and if present, it enables the DP pullup and if Reset is detected (i.e. both DP and DM goes down), the DFU bootloader is started. Whether it implements some sort of timeout and goes out of DFU bootloader if there is no enumeration from the host (PC) side, I don't know.

JW

[rammit]

Ahh ok. That helps. So if it just a matter of DP going low a short while after reset, assuming DM is already low, than I can see how our design might be going into the USB bootloader. I'll try to get more info from ST. Thanks!

[rammit]

ST was no help.

By pulling PA11 (USB_DM) high the blank chip did NOT go into the USB bootloader and we were able to access the UART bootloader. So, it looks like it is just looking for a static state of pins PA11 and PA12. Not ideal, but should be documented somewhere.