Posted on June 07, 2017 at 14:51- 'DWORD' usage
- there is no description of function/purpose of OTG_HS_DEACHINT / OTG_HS_DEACHINTMSK / OTG_HS_DIEPEACHMSK1 / OTG_HS_DOEPEACHMSK1 registers. Moreover, in Table206, OTG_HS_DEACHINT is mis-spelled as OTG_HS_EACHHINT, and OTG_HS_DEACHINTMSK is mis-spelled as OTG_HS_EACHHINTMSK
- additionally to unexplained 'alternative' usage marks to register bits, as reported in 3.post of this thread (and there are quire a bit more than just listed in that post), there are also bits with no usage marks at all, e.g. some bits of OTG_HS_DIEPINTx and OTG_HS_DOEPINTx, and OTG_HS_DIEPDMAx/OTG_HS_DOEPDMAx, and there are more.
- there is a *blue* equal-mark in STUPCNT = 3, two instances
Reported to be managed as document (RM0090) related
Moreover, in the CMSIS device header, the respective fields to 3 of these four registers have non-corresponding names, adding to the confusion.
I confirm this for
OTG_HS_DIEPEACHMSK1 and OTG_HS_DOEPEACHMSK1. I will check where the error is (CMSIS header files or RM0090) and then let you know.
- there is no 'Direct access to data FIFO RAM' in 'L4's RM. It's a pity, an extra kilobyte of RAM may come handy at times, even if it is potentially slower and 'there is plenty RAM anyway'. Comment, please.
To be checked
-
in the CMSIS stm32YYYYxxx.h headers, USB_OTG_FS and USB_OTG_HS symbols are defined using the USB_OTG_GlobalTypeDef structure, which contains only the 'global' registers. Other registers are accessed in the library through ad-hoc concocted macros, inconsistent with the style of the CMSIS header. It's not that hard to write a typedef containing all the registers of the USB IP, even being fully backwards compatible. Please think about it.
What 'Other registers' are missing in CMSIS header files? Could you please explain and provide examples?
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
