STM32 Hardware implementation USB Host vs Device

[Joe.H]

I want to use a STM32G4 device in a new project but I was disappointed to find the USB implementation only supported Device mode.

What is the hardware (implemented in the MCU) that make it capable of host mode from device mode (OTG supports both)?  Without knowing the answer - can the missing hardware be implemented in software using the USB cell made for just device mode?  Thanks. 

[AScha.3]

>What is the hardware (implemented in the MCU) that make it capable of host mode

Its just another controller, more complex.

> can the missing hardware be implemented in software using the USB cell made for just device mode?

No.

If you want an host controller, choose a cpu that has it on its chip (maybe 50 ct more to spend...). :)

[Joe.H]

Thanks for the reply.  I was looking/hoping for a mcu that had BOTH USB Host mode and OP Amps that worked with the ADCs.  No such luck with the STM32G4 family.

[AScha.3]

So maybe helping , to find a cpu, that matches your idea:

https://www.st.com/en/development-tools/st-mcu-finder-pc.html

 

[FBL]

Hi @Joe.H 

Check section 1.5 Availability of peripherals in RM0440

This should be included as well in AN4879. Ticket 152751

[waclawek.jan]

@Joe.H,

external opamps may also result in better analog performance than what you'd get from the internal ones. OTOH, I'd recommend you to benchmark the 'F4 ADCs first, e.g. using a cheap Nucleo board, before you commit to a particular design. As an alternative, you might perhaps want to consider the higher-end 'L4 ('L475 and up).

 

@FBL

AN4879 could use a thorough review.

'G0Bx/Cx is missing entirely.

The C cathegory in Table 3 does have integrated FS PHY (the footnote says so, but table itself incorrectly says "-" for "none").

The description of OTGs in 'H7 family is a mess, which is perpetuated from the mess in the DS/RM. They are not that different from the 'F4/'F7 to grant a different denomination, which just serves increased confusion.

Table 1 is missing the 'F72x/73x, although they are present later.

JW

[FBL]

 

Hi @waclawek.jan 

I can confirm G0Bx/Cx is missing. Also, "-" is confusing, the footnote explains better. Maybe, the column Integrated PHY should be remove and leave explanation in footnote since we are running out of space.

Migration guide Table 33 in AN5293 should explain the main differences between H7 and F7. Ticket #185616 to clarify the footnote as well.  Would you @waclawek.jan specify which description of OTGs in 'H7 family is incorrect?

An internal ticket 185623 to update Table 1 and table 3 in AN4879. It is indeed missing the F72x/73x, H7Sxx and more,

[waclawek.jan]

Hi @FBL ,

(At this point we have hijacked the original thread to a very diverse direction; perhaps you may want to split this part to a separate thread.)

> Would you @waclawek.jan specify which description of OTGs in 'H7 family is incorrect?

The USB implementations in 'H7 ('H743) are defacto identical to 'F2/'F4/'F7: one OTG with FS PHY; and one OTG with both FS PHY and ULPI interface. It's quite logical to call them OTG_FS and OTG_HS respectively. However, ST decided to call them OTG_HS1 and OTG_HS2, with footnotes indicating that OTG_HS2 is not HS.

Now I understand that the original design target in 'H743 might've been different and that both OTGs might've been targeted to have an ULPI, and for whatever reason - marketing decision (I can imagine the "FS" OTG does have the ULPI interface integrated it's just not documented for marketing reasons), technical difficulties (we know there were many with the 'H743)  - they ended up in this mix. But that's all irrelevant from user's point of view; user sees the same USB setup than in 'F7 - one FS-potentially-HS and one FS-only - and it is very confusing that it's called differently.

(IIRC the CMSIS-mandated device header called them OTG_HS and OTG_FS ever since, but I may remember it incorrectly).

I ranted about this early (lazy to look up that thread) but I don't use the 'H7 at all, so had to look now again, and what I see in the documentation is an incompletely and maybe even more confusingly executed rename. For example, 'H743 DS:

'H743 RM appears not to be touched at all in the most important parts:

Textual search in RM reveals a couple of OTG_FS references, though, e.g. one in Fig.750 which goes "OTG_HS2, alias OTG_FS" with footnote saying "This instance cannot be used in HS mode for pinning reasons." That may be the historical reason I've talked about above, but to the user this does not help, it's completely irrelevant why it cannot be used. If user cannot use a feature for whatever reason beyond their decision, that feature practically does not exist and should not be mentioned at all (for example, if there would be a variant of 'H7 where the ULPI in the second OTG would be accessible, that would be a different story; but as far as I can see, this is not the case). Thus a systematic rewrite of the RM is needed, to be in line with the _HS/_FS nomenclature already implemented (albeit with above errors) in the DS. Mismatch of DS and RM is not an acceptable option.

(An even more bizarre reference to OTG_FS in RM is in changelog where it refers to an entire OTG_FS section, maybe indicating that there was such already in the RM rev.7, I don't have historical RMs for the 'H7 to look up and it's not that important from the status quo either).

 

There's absolutely no reason then also to retain the different-than-'F4/'F7 description in AN4879 (including footnote), either

And the same applies to the migration AN5293, too.

JW

 

[FBL]

I agree @waclawek.jan. Cross reference information and naming's are confusing and can be misinterpreted.

Overall, A ticket 185786 is submitted to dedicated team to address these inconsistencies in DS RM and migration guide App Note. 

Thank you!

>"FS" OTG does have the ULPI interface integrated it's just not documented

Sorry, but Figure 749. USB1 OTG_HS high-speed block diagram (OTG_HS1) shows that the PHY is external component. 

> we have hijacked the original thread to a very diverse direction

I thought @Joe.H figured out a solution : "It looks like I'm going to use a stm32F411/412 and have to add my opamps discreetly to the pcb."