'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 June 15, 2016 at 17:51

[Only marginally related to the original post, so I should've started a new thread, but don't want to flood the forum.]

In description of both OTG_DAINT and OTG_DAINTMSK is the following:One bit per OUT endpoint: Bit 16 for OUT endpoint 0, bit 18 for OUT endpoint 3. Shouldn't that read asBit 16 for OUT endpoint 0, bit 19 for OUT endpoint 3. ? I've found it both in RM0351 and RM0090 (both for FS and HS); didn't search further but I believe this will be accross all RMs containing USB. JW

[waclawek.jan]

Posted on June 15, 2016 at 18:22

[Another marginally related question, again don't want to start a new thread to avoid forum flooding]

In RM0351, bit B2BSTUP in OTG_DOEPINTx, and bit INEPNE in OTG_DIEPINTx, are marked as rc_w1/rw . There is no such abbreviation in the list in chapter 1.1. What does that exactly mean, then? JW

[waclawek.jan]

Posted on June 15, 2016 at 19:14

[More]

In HAL_PCD_IRQHandler() in [STM32Cube_FW_L4_V1.5.0]\Drivers\STM32L4xx_HAL_Driver\Src\stm32l4xx_hal_pcd.c , when handling the Transfer Complete interrupt for any Out Endpoint, the following is executed:            if ((( (USBx_OUTEP(0)->DOEPINT & 0x8000) == 0)) )             {                              if(hpcd->Init.dma_enable == 1)               {                 hpcd->OUT_ep[epnum].xfer_count = hpcd->OUT_ep[epnum].maxpacket- (USBx_OUTEP(epnum)->DOEPTSIZ & USB_OTG_DOEPTSIZ_XFRSIZ);                 hpcd->OUT_ep[epnum].xfer_buff += hpcd->OUT_ep[epnum].maxpacket;                           }                              HAL_PCD_DataOutStageCallback(hpcd, epnum);                              if(hpcd->Init.dma_enable == 1)               {                 if((epnum == 0) && (hpcd->OUT_ep[epnum].xfer_len == 0))                 {                   /* this is ZLP, so prepare EP0 for next setup */                   USB_EP0_OutStart(hpcd->Instance, 1, (uint8_t *)hpcd->Setup);                 }                             }             }             /* Clear the SetPktRcvd flag*/             USBx_OUTEP(0)->DOEPINT |= 0x8020; Needless to say, bits 5 and 15 of all endpoints' (including EP0) DOEPINT register are marked as reserved. ST, please, comment. JW

[Amel NASRI]

Posted on June 20, 2016 at 15:54

Hi waclawek.jan,

Your comments are shared internally for further review. I will keep you informed about the taken actions/explanation if needed.-Mayla-

[waclawek.jan]

Posted on June 20, 2016 at 16:37

Mayla,

thanks for taking care. Jan

[waclawek.jan]

Posted on June 20, 2016 at 16:48

[More...]

In [STM32Cube_FW_F4_V1.12.0\Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_pcd.c , HAL_PCD_IRQHandler() , a local variable hclk is initialized and then, without any modification, tested to determine TRDT in an if-then chain. Apparently, call to a function to determine the configured hclk is missing. JW

[waclawek.jan]

Posted on June 29, 2016 at 15:49

[More...]

In [STM32Cube_FW_F4_V1.12.0]\Middlewares\ST\STM32_USB_Device_Library\Class\CDC\Src\usbd_cdc.c , this ''function header'' (comment) is misleading (result of copy/paste): /**   * @brief  USBD_CDC_DataOut   *         Data received on non-control Out endpoint   * @param  pdev: device instance   * @param  epnum: endpoint number   * @retval status   */ static uint8_t  USBD_CDC_EP0_RxReady (USBD_HandleTypeDef *pdev) { JW

[waclawek.jan]

Posted on August 31, 2016 at 18:34

Hi Tsuneo,

Thank you for your reply. > In DMA mode, the USB core transfers the SETUP packet to specified memory address (ie. above Setup[]). But the manual doesn't clearly describe how many bytes should be transferred. And then, for safety reason, three DWORDs are assigned. There is surprisingly little information available for the details of DMA in OTG_HS, but I would be surprised if it would transfer anything more than what has been set in DOEPCNT0.XFERSIZ and that's 3*8 (bytes), see USB_EP0_OutStart(). So I would not call it ''safety reason''... except that there's uint32_t[12] which is 48 bytes, which is twice as much as the maximum required 3*8=24 bytes... and given the way how incoming data are handled, these 24 bytes would be needed in the DMA-less mode too. I expect some handwaving when it comes to 24 bytes of RAM in these days of PLENTY of RAM available, but I deem it to be a shame to allocate more memory than needed, call me old fashioned. > I believe the USB sections of the reference manual are provided by Synopsys, the USB IP provider of this family. That's no secret, it's said so at the beginning of the USB chapter in the RM. > ST should claim newer revision of the USB sections to Synopsys. Maybe, but I don't really care - it's ST's manual thus ST's responsibility to clean up the mess. > SiLabs EFM32 also integrates (almost) the same USB IP, and their manual is a little better than STM32's. Thanks for pointing this out; I can compare in cases of doubts (although there will be differences due to different IP configuration and revision undoubtedly). > DWORD This appears to mean ''4-bits''. This is unusual in the ARM world, where ''word'' is used to mean 4-bits. The USB chapter is also the only place where DWORD appears throughout that ''gecko'' RM. Oh, of course I looked up STM32F4's RM0090 for DWORD... sure enough, it shows up in the Synopsis IP's chapters, ETH, OTG_FS and OTG_HS. ST appears to have purged most of it from OTG_FS where it appears only in 3 places (and replaced by ''Word'' (capitalized in this way)); less than in OTG_HS and ETH. Cm'on, ST, this is a find-and-replace operation, how hard it may be? Jan

[waclawek.jan]

Posted on August 31, 2016 at 18:38

Any response to the already internally reported stuff, especially post 4, i.e. use of undocumented DOEPINT bits in Cube?

I thought the Cube crew is responsive... JW