2017-08-24 02:47 PM
More (Cube, both L4 and F4).
Why does Cube write to DAINT, once it's read only?
And why does it handle GINTSTS.MMIS interrupt, once it was never enabled?
JW
2017-09-29 08:53 AM
Hi Jan,
Could you please provide more details regarding this point:
And why does it handle GINTSTS.MMIS interrupt, once it was never enabled?
Many thanks.
Khouloud.
2017-10-02 03:44 AM
Khouloud,
my point was, that - contrary to other handled GINTSTS flags/interrupts - handling MMIS does not involve a callback to user code, thus it's obviously treated as purely internal to the library. So I would expect the library enables that interrupt (in USB_DevInit()) once it's handled only internally.
OTOH, the whole concept is flawed - this interrupt is aimed at catching programmer errors, so there's no point in silently clearing it, contrary, it should be exposed to the programmer, IMHO.
As you are surely aware I don't really care about Cube as such, but due to the woeful state of available documentation I am forced to use it as an additional source of information, and - as you can see from the number of my posts related to OTG+Cube here - it sometimes results in more questions than answers...
Jan
2017-10-02 11:42 AM
I am not the first to ask about the write to read-only DAINT:
JW
2017-11-20 03:02 AM
Hi
Waclawek.Jan
,Why does Cube write to DAINT, once it's read only?
-> Issue confirmedand will be rectified in future versions.Many thanksfor bringing this point to our attention.
And why does it handle GINTSTS.MMIS interrupt, once it was never enabled?
->
if(__HAL_PCD_GET_FLAG(hpcd, USB_OTG_GINTSTS_MMIS)) { /* incorrect mode, acknowledge the interrupt */ __HAL_PCD_CLEAR_FLAG(hpcd, USB_OTG_GINTSTS_MMIS); }
This code is used to track any mismatch access on the IP registers (access host registers while the core is configured in device mode..)
Even if MMIS interrupt is not enabled in our current HAL, we should keep this code in the interrupt Handler in case Customer wants to use this feature.
Khouloud.