Hi @Joe.H
Check section 1.5 Availability of peripherals in RM0440
This should be included as well in AN4879. Ticket 152751
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,
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
