2016-06-15 08:31 AM
According to RM0351 Rev.4, all OTG_GINTSTS (interrupt status register) bits are rc_w1 (except those which are read-only or reserved). However, the macro supposed to be used for clearing these bits in [STM32Cube_FW_L4_V1.5.0]\Drivers\STM32L4xx_HAL_Driver\Inc\stm32l4xx_hal_pcd.h goes:
#define __HAL_PCD_CLEAR_FLAG(__HANDLE__, __INTERRUPT__) (((__HANDLE__)->Instance->GINTSTS) &= (__INTERRUPT__)) Not a hard bug, but IMO the RMW is redundant. Am I overlooking something? JW2016-08-31 10:04 AM
More.
- ''DWORD'', mentioned in previous post - 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 . Moreover, in the CMSIS device header, the respective fields to 3 of these four registers have non-corresponding names, adding to the confusion. - 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 - 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. - 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. Thanks, JW2016-08-31 01:14 PM
More (still RM0090, rev.12):
- in Tab.206 the text for OTG_HS_DOEPINTx is copy/pasted from OTG_HS_DIEPINTx, including the link. The same goes for OTG_FS_DOEPINTx in Tab.198. - in both Tab198 and Tab.206, the endpoint-dependent registers have inconsistently displayed their address offset - some list multiple addresses, some list only one address - OTG_HS_DIEPINTx contains BERR and NAK bits, for which there appear to be no mask bits. However, the Cube FW does not handle them, indicating that they *are* masked somehow. Also, why would an *IN* endpoint indicate babble? Please explain. - similarly, OTG_HS_DOEPINTx contains a NYET bit, with apparently no corresponding mask in OTG_HS_DOEPMSK. OTOH, in OTG_HS_DOEPMSK there are two masks, OPEM and BOIM, with no corresponding interrupt flags in OTG_HS_DOEPINTx. - the mysterious (see post above) OTG_HS_DOEPEACHMSK1 contains a mask for babble error (mis-spelled as ''bubble error'' :) ) and also for NAK and NYET; however, that would be only for EP1, and still does not explain other inconsistencies mentioned above. Please clean up thoroughly. - speaking of babble, in OTG_FS in the list of [device a.k.a. peripheral] endpoint status/interrupt on p.1253 (part of USB peripheral sub-chapter), mentions ''Babble error condition has been detected''; however, there is no mention of babble error bit/mask in OTG_FS_DOEPMSK nor OTG_FS_DOEPINTx - OTG_HS_DOEPDMAx is missing from Tab.206 - OTG_HS_DIEPDMA0/OTG_HS_DOEPDMA0 missing from Tab.211 and both at description of OTG_HS_DIEPDMAx/OTG_HS_DOEPDMAx at p.1468 and in Tab.206 there is ''x = 1..5''. Does this mean that EP0 is NOT handled by DMA? The Cube software appears to indicate otherwise. Also the footnote of registers description on p.1468 mentions ''control endpoints'' which in every practical USB implementation implies EP0, which would also indicate that DMA *is* available for EP0. Explain/clean-up, please. - what are the OTG_HS_DIEPDMABx/OTG_HS_DOEPDMABx registers in Tab.211? - PLEASE sort Tab.211 in ascending register address/offset - also please don't intertwine the IN and OUT inedpoints' registers in the registers section (following address/offset order would be more logical, too) - most of the OTG_HS registers are missing from the Index at the end of RM - even if this has been cleaned up already a bit, there are still inconsistent hexadecimal numbers (with h suffix) around, e.g. in the CSR memory map (and in other chapters e.g. ETH, SDIO) too. Searching for ''00h'' reveals quite a few of them even if not all. The funniest is ''0xX000h'' in Tab.207 (note that the ''parallel'' Tab199 is OK). These all are randomly spotted apparent errors. The functional description was hard to read and it is likely to contain deficiencies if not outright errors too. I don't work on Host nor OTG so I expect there are much more; both chapters deserve a thorough cleanup. Oh, I know, handwaves and pointing to Cube; again, I am old fashioned but IMO datasheet/manual comes first. JW2016-09-08 11:24 AM
More
In [STM32Cube_FW_F4_V1.12.0]\Middlewares\ST\STM32_USB_Device_Library\Core\Src\usbd_core.c: [...] if (pdev->dev_test_mode == 1) { USBD_RunTestMode(pdev); pdev->dev_test_mode = 0; } [...] where USBD_RunTestMode() is internal to that module and does nothing: USBD_StatusTypeDef USBD_RunTestMode (USBD_HandleTypeDef *pdev) { return USBD_OK; } These are obviously relicts from internal development and should be purged from final code (together with dev_test_mode field from the dev struct). JW PS. Any news about the already internally reported things?2016-09-13 11:56 PM
Hi Jan,
As there are so many issues reported here regarding various resources, I will provide you answers case by case (when I have details to share :)):- The issue reported in the post of6/20/2016 4:48 PM
was fixed in STM32CubeF4 V1.13.- The issue reported in the post of6/15/2016 6:22 PM,
the following update will be done in the reference manual: INEPNE is “r� (read only), B2BSETUP is “rc_w1�.To be continued...-Mayla-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.
2016-09-14 04:14 AM
Thanks, Mayla.
> To be continued... Looking forward to. :) Jan2016-11-30 08:51 AM
I'd like to revive this thread because I'm having a lot of problems that are similar to what Jan is having, except I'm working with the STM32F74xxxx, so I'm looking at RM0385.
I'm especially interested in Jan's fourth post on this thread, which includes this line>
if ((( (
USBx_OUTEP(0)->DOEPINT & 0x8000) == 0)) )
As Jan points out, >bits 5 and 15 of all endpoints' (including EP0) DOEPINT register are marked as reserved.There is no resolution given in the thread. Has anyone found out anything about this?2016-11-30 09:05 AM
Another question:
Why is only 1 bit while is 2 bits?According to , >On receiving the PKTCNT number of USB packets, the core internally sets the NAK bitfor this endpoint to prevent it from receiving any more packetsSo what is the point of having STUPCNT = 3 if PKTCNT can be no more than 1?@Jan - maybe we should write our own datasheet once we get this mess figured out.2017-01-16 02:41 AM
Hi Mayla,
> To be continued...
Any news?
Jan
2017-01-16 04:05 AM
Hi Jan,
'Mayla' becomes 'Amel N' in new community
I'll come back to this discussion to review remaining open points.
-Amel
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.
2017-01-16 04:19 AM
Amel,
OK, standing by :) Thanks.
Jan