I am writing a host stack and I have noticed various issues with the documentation and the hardware.
The pdf index of the Reference Manual (RM) for F2 series (DocID15403 Rev 6) is broken. If you open the index (contents) for the OTG FS and OTG HS registers it shows tables and notes instead of registers.
According to the RM the PENA bit in the OTG_HS_HPRT is rc_w0.
“The application cannot set this bit by a register write. It can only clear it to disable the port.”
I had checked all the usb libraries I could find on internet and indeed they NEVER write this bit with 1.
But they all write it with 0 even when the port is obviously powered (e.g. when performing a bus reset).
So the libraries treat this bit as rc_w1 while the RM says it is rc_w0.
Which is correct?
The power up sequence of the OTG controller is not documented well. There are some complication when using the OTG HS with the internal FS PHY and it is even more complicated when the ID pin is not used. The software is supposed to reset the core and phy domain when changing the PHY. Then some configuration needs to be done until we are able to detect a connection. And then if we have configured different speed than the one that the device requires we need to change the PHY clock.
With other words several resets may be required, and after each reset some registers are cleared and needs to be reconfigured. But all this needs to be done with caution if we do not want to loop forever with resets.
I did it somehow, but it will be nice to have some documentation about the steps – in which order to change the PHYs, the host/device mode, power, clocks... how long each step can take etc.
CHENA and CHDIS bits in OTG_HS_HCCHARx / OTG_FS_HCCHARx register.
Again bits which can be modified from both the software and hardware and again contradictory documentation and practice. The definition is “rs” but how can you explain “HCCHARx = CHDIS” and “HCCHARx = CHENA | CHDIS”?
Btw it is not very clear how the core modifies these bits and when. I have noticed that on the control IN endpoints the core disables the channel on the first NAK, while for the interrupt IN type it does not disables the channel.
The NAK processing is not documented well.
I think it is worth mentioning that the host must send regularly IN tokens to poll the in channels. And most of the time the device is not ready or has no data, so we can expect some NAKs....
There is a section “NAK and NYET handling with internal DMA” but what about without DMA?