STM32F4 & STM32F7 USB Host Core (Interrupt flood)

[Tim Michals]

Posted on May 19, 2017 at 01:02

Issue:

USB Core issing interrupt at a rate of 8.65us causing high CPU loading.

Software/Chip:

Using USB Host/CDC from STM32Cube V1.15 on a STM32F429 board. 

  USB interrupt sources:

- SOF Interrupts (It is not needed for CDC type transfers) turned this interrupt off and still getting high interrupt rate.

   This is configured in

HAL_StatusTypeDef USB_HostInit (USB_OTG_GlobalTypeDef *USBx, USB_OTG_CfgTypeDef cfg)

.....

  /* Enable interrupts matching to the Host mode ONLY */

  USBx->GINTMSK |= (USB_OTG_GINTMSK_PRTIM            | USB_OTG_GINTMSK_HCIM |\

                 

   USB_OTG_GINTMSK_SOFM

|USB_OTG_GINTSTS_DISCINT|\

                    USB_OTG_GINTMSK_PXFRM_IISOOXFRM  | USB_OTG_GINTMSK_WUIM);

 

  return HAL_OK;

}

- NAK interrupts from bulk in endpoint.  The issue is when the OTG USB gets enough NAKs from the bulk endpoint and issues an interrupt at a rate of 8.625us. 

Solutions

?

Is there a work around that does not degrade USB performance?  The STM32FH7 also has has the same code to re-enable the bulk in endpoint. 

static void HCD_HC_IN_IRQHandler   (HCD_HandleTypeDef *hhcd, uint8_t chnum)

  }

  else if ((USBx_HC(chnum)->HCINT) &  USB_OTG_HCINT_NAK)

  {   

    if(hhcd->hc[chnum].ep_type == EP_TYPE_INTR)

    {

      __HAL_HCD_UNMASK_HALT_HC_INT(chnum);  

      USB_HC_Halt(hhcd->Instance, chnum);   

    }

    else if  ((hhcd->hc[chnum].ep_type == EP_TYPE_CTRL)||

         (hhcd->hc[chnum].ep_type == EP_TYPE_BULK))

    {

      /* re-activate the channel  */

      tmpreg = USBx_HC(chnum)->HCCHAR;

      tmpreg &= ~USB_OTG_HCCHAR_CHDIS;

      tmpreg |= USB_OTG_HCCHAR_CHENA;

      USBx_HC(chnum)->HCCHAR = tmpreg;

    }

    hhcd->hc[chnum].state = HC_NAK;

    __HAL_HCD_CLEAR_HC_INT(chnum, USB_OTG_HCINT_NAK);

  }

}

There are several postings about this issue (The first posting is the best description of the issue)

https://community.st.com/0D50X00009XkYz2SAF

 

https://community.st.com/0D50X00009XkYSSSA3

 

https://community.st.com/0D50X00009Xked0SAB

 

null

[Jim Kaz]

Hi @IUcha.843​ ,

If it makes you feel any better, I ported my own change to an H743 Eval board with the H7 v1.5.0 and it seems to work properly (at least from what I can tell). I have a kind of unique set up where I have an eval board connecting to my computer as a USB device, which it then communicates over an CAN-FD bus to another Eval board connected as a USB host to a Rasberry Pie and I am able to send ethernet traffic to the Rasberry Pie and transfer a file via WinSCP (my USB nodes enumerate as RNDIS devices, which is a specialized form of CDC that makes it look like an ethernet connector). With this bizarre setup I am able to transfer a file from the Rasberry Pie, to the node acting as a USB host, over a CAN-FD network to a node acting as a USB device to my computer at rates of around 3 Mb. I suspect I could get this number higher by running the processor faster (only running at 100Mhz for power reasons) and further optimizations, but the project is still in it's infancy.

So, as far as I can tell, it does work without any undue side effects, though I'd love for the actual developers to take a look at it and let us know if it's safe :grinning_face:

[ThomasK]

Hi,

I observe the same problem using the NUCLEO-L496ZG board. The firmware hangs after a call to USBH_CDC_Receive until some data arrives. I use the FW_L4 V1.17.0 HAL. For testing, I talk to an MCP2221 USB/Serial converter. As soon as I send some data on the serial wire, the firmware continues.

Is there any plan to address this problem or a workaround?

Regards,

Thomas

[laurentc]

ST teams, this issue has been pending for 7 ***ing years - have some respect for the life of your clients !!

Do you realize how many man days have been lost by your clients because of that ?

The patches provided by ST are now impractical.

It is impossible to do a proper winmerge with the latests fw because the files have changed everywhere.

Any update regarding this topic for H7 ?