'L4 Cube - clearing OTG_GINTSTS bits

[waclawek.jan]

Posted on June 15, 2016 at 17:31

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? JW

[waclawek.jan]

Posted on August 31, 2016 at 19:04

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, JW

[waclawek.jan]

Posted on August 31, 2016 at 22:14

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. JW

[waclawek.jan]

Posted on September 08, 2016 at 20:24

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?

[Amel NASRI]

Posted on September 14, 2016 at 08:56

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 of

6/20/2016 4:48 PM 

was fixed in STM32CubeF4 V1.13.- The issue reported in the post of

6/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-

[waclawek.jan]

Posted on September 14, 2016 at 13:14

Thanks, Mayla.

> To be continued... Looking forward to. :) Jan

[John Mamish]

Posted on November 30, 2016 at 17:51

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?

[John Mamish]

Posted on November 30, 2016 at 18:05

Another question:

Why is

http://www.st.com/content/ccc/resource/technical/document/reference_manual/c5/cf/ef/52/c0/f1/4b/fa/DM00124865.pdf/files/DM00124865.pdf/jcr:content/translations/en.DM00124865.pdf#page=1399

only 1 bit while 

http://www.st.com/content/ccc/resource/technical/document/reference_manual/c5/cf/ef/52/c0/f1/4b/fa/DM00124865.pdf/files/DM00124865.pdf/jcr:content/translations/en.DM00124865.pdf#page=1399

is 2 bits?According to

http://www.st.com/content/ccc/resource/technical/document/reference_manual/c5/cf/ef/52/c0/f1/4b/fa/DM00124865.pdf/files/DM00124865.pdf/jcr:content/translations/en.DM00124865.pdf#page=1462

, >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.

[waclawek.jan]

Posted on January 16, 2017 at 10:41

Hi Mayla,

> To be continued...

Any news?

Jan

[Amel NASRI]

Posted on January 16, 2017 at 12:05

Hi Jan,

'Mayla' becomes 'Amel N' in new community

I'll come back to this discussion to review remaining open points.

-Amel

[waclawek.jan]

Posted on January 16, 2017 at 12:19

Amel,

OK, standing by :) Thanks.

Jan