Posted on May 25, 2018 at 18:17I ran into the same issue with an L4 processor and I found a way to work around it that seems to work. I've never looked at any of the F series software frameworks, but I suspect something similar to what I did will work. I made the following 2 changes.
Inside of the interrupt, where you handle the NAK interrupt, I disable it. Below is what it looks like on the L4 framework (line I added is in bold):
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);
}
/* Clear the NAK flag before re-enabling the channel for new IN request */
hhcd->hc[chnum].state = HC_NAK;
__HAL_HCD_CLEAR_HC_INT(chnum, USB_OTG_HCINT_NAK);
// Hack to disable the NAK interrupt completely (it'll be re-enabled in SOF) USBx_HC(chnum)->HCINTMSK &= ~USB_OTG_HCINT_NAK; if ((hhcd->hc[chnum].ep_type == EP_TYPE_CTRL)||
(hhcd->hc[chnum].ep_type == EP_TYPE_BULK))
{
/* re-activate the channel */
USBx_HC(chnum)->HCCHAR &= ~USB_OTG_HCCHAR_CHDIS;
USBx_HC(chnum)->HCCHAR |= USB_OTG_HCCHAR_CHENA;
}
}
This change by itself will break USB as the NAK interrupt does appear to be important for general functionality. You have to periodically re-enable the NAK interrupt, and I used the SoF interrupt to do that.
/* Handle Host SOF Interrupts */
if(__HAL_HCD_GET_FLAG(hhcd, USB_OTG_GINTSTS_SOF))
{
HAL_HCD_SOF_Callback(hhcd);
__HAL_HCD_CLEAR_FLAG(hhcd, USB_OTG_GINTSTS_SOF);
// Added hack to re-enable the NAK interrupt because leaving it off is bad for (i = 0; i < hhcd->Init.Host_channels; i++) { USBx_HC(i)->HCINTMSK |= USB_OTG_HCINT_NAK; } }
Re-enabling it for every channel is probably unnecessary, but since this is running in interrupt space I opted for speed rather than checking each channel and seeing if it needed to be re-enabled.
I was getting interrupts every 20 microseconds This change made it so I'd get the SOF interrupt once a ms, then 20 us later get a NAK and then no spurious interrupts until the next SOF.
