Super User

Question

'L4 Cube - clearing OTG_GINTSTS bits

Forum|Forum|9 years ago
June 15, 2016
17 replies
4791 views

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

This topic has been closed for replies.

waclawek.janAuthor

Super User

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 as

Bit 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

Amel NASRI

ST Technical Moderator

Posted on June 02, 2017 at 16:23

Fixed in RM0351 Rev5
Reported for other remaining reference manuals

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.

waclawek.janAuthor

Super User

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

Amel NASRI

ST Technical Moderator

Posted on June 02, 2017 at 16:43

Alreadu updated:

INEPNE is â€œrâ€� (read only), B2BSETUP is â€œrc_w1â€�.

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.

waclawek.janAuthor

Super User

Posted on June 07, 2017 at 23:15

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?

Already updated:

INEPNE is “r�? (read only), B2BSETUP is “rc_w1�?.

Yes, updated in RM0351 (in rev.5 as of now), but not in RM0090 (rev.14) - both FS and HS.

There is at least a dozen of RMs containing the Synopsis USB IP in some version and configuration (L4/F2/F4/F7 if I am not mistaken), some of them with two separate instances of that text, for FS and HS. (Just as a quick test - I looked at B2BSTUP and INEPNE in RM0410 and yes, they are marked 'rc_w1/rw'). What's the point in updating only one of them, just because a user happened to stumble upon that one?

The same applies to all my documentation-related rants in this thread, including that to which you replied: '

Reported to be managed as document (RM0090) related' (although .

I understand you are following an internal report procedure, and I also understand how tedious is it to go through all related documents and fix them all, especially since I guess there are separate teams maintaining the individual sub-families' documentation; however, IMO there's no point in doing that at all and it's wasting both my and your time, if the result is to be half-baked.

Thank you for your tireless work.

Jan

waclawek.janAuthor

Super User

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

ST Technical Moderator

Posted on June 02, 2017 at 16:45

Bits 5 and 15 of DOEPINT shouldn't be reserved ==> to be confirmed and description of bits will be provided soon

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.

Amel NASRI

ST Technical Moderator

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-

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.

waclawek.janAuthor

Super User

Posted on June 20, 2016 at 16:37

Mayla,

thanks for taking care.

Jan

waclawek.janAuthor

Super User

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

Amel NASRI

ST Technical Moderator

Posted on June 06, 2017 at 14:23

Issue fixed since the version 1.0 of STM32CubeF4 package adding this call:

/* Get hclk frequency value */
 hclk = HAL_RCC_GetHCLKFreq();�?�?

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.

waclawek.janAuthor

Super User

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

Amel NASRI

ST Technical Moderator

Posted on June 06, 2017 at 14:58

This error is already tracked internally, but it seems fix not yet applied. I will check this.

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.

waclawek.janAuthor

Super User

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

Amel NASRI

ST Technical Moderator

Posted on June 06, 2017 at 15:17

The context seems to be missing, as if there is a post lost in this discussion.

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.

waclawek.janAuthor

Super User

Posted on June 06, 2017 at 15:43

In attachment the saved content of this thread from the old forum in MHTML format, together with Tsuneo's post.

Jan

________________

Attachments :

Forum - 'L4 Cube - clearing OTG_GINTSTS bits - STMicroelectronics.mht : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HycU&d=%2Fa%2F0X0000000bAA%2FdzUVxWWkDMfySkGWbYO6Qwl7_sYoRA4zIRRXWJ1ATnk&asPdf=false

waclawek.janAuthor

Super User

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

waclawek.janAuthor

Super User

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

Amel NASRI

ST Technical Moderator

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 "Best Answer" on the reply which solved your issue or answered your question.

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded