USB High Speed

[Alexander Skupov]

Posted on January 25, 2018 at 11:44

Hi all

I'm using stm32f745  with the CubeMX USB OTG Host library

I constantly send requests to another device.

But at one point I take one zeros

If you use full speed, then this problem does not arise

Similarly, if you add a printf('nak') to

static void HCD_HC_IN_IRQHandler (HCD_HandleTypeDef * hhcd, uint8_t chnum) {

........

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);

printf('nak \r\n');

   }

}

the problem disappears

Help me please

[Rick Sladkey]

Posted on February 09, 2018 at 01:47

I seem to be having the same or a similar problem and have narrowed down the issue to the area of code you highlighted.

During 'correct operation' of USB high speed host stack with an outstanding bulk read URB, if the device does not have any data, the channel is continually naked and immediately re-enabled by

HCD_HC_IN_IRQHandler

 as you have highlighted. However, at some point (and for me this happens almost immediately), the nak interrupts stop and the channel is hung with the CDC class stuck in the CDC_RECEIVE_DATA_WAIT state.

I have not tried your 'printf' workaround because what printf does depends a lot on the development environment. In my case, it is not safe to call printf from an interrupt handler.

I had a suspiciously similar problem with sending data, as described in this post:

https://community.st.com/message/78380

[Rick Sladkey]

Posted on February 09, 2018 at 05:33

Search the forum I found this other thread:

The suggested approach of completing the transaction at NAK solves two problems for me:

1. The bulk IN-NAK hang problem discussed in this thread
2. The bulk IN-NAK flood problem discussed in that thread

It's not an ideal solution because it requires modifying the code generated by CubeMX and because it doesn't address the cause of the hang, which might still be a latent bug.

This snippet gives an idea of the changes required instm32f7xx_hal_hcd.c which causeUSBH_CDC_ReceiveCallback (I'm using CDC) to be called with zero-length packet, at which point you can schedule another receive.

 else if ((USBx_HC(chnum)->HCINT) & USB_OTG_HCINT_TXERR) { __HAL_HCD_UNMASK_HALT_HC_INT(chnum); hhcd->hc[chnum].ErrCnt++; hhcd->hc[chnum].state = HC_XACTERR; USB_HC_Halt(hhcd->Instance, chnum); __HAL_HCD_CLEAR_HC_INT(chnum, USB_OTG_HCINT_TXERR); }#if 1 // Workaround for bulk IN-NAK flood suggested here: // https://community.st.com/thread/31809 else if ((USBx_HC(chnum)->HCINT) & USB_OTG_HCINT_NAK && hhcd->hc[chnum].ep_type == EP_TYPE_BULK && hhcd->hc[chnum].ep_is_in) { __HAL_HCD_UNMASK_HALT_HC_INT(chnum); USB_HC_Halt(hhcd->Instance, chnum); hhcd->hc[chnum].state = HC_XFRC; hhcd->hc[chnum].ErrCnt = 0; __HAL_HCD_CLEAR_HC_INT(chnum, USB_OTG_HCINT_NAK); }#endif else if ((USBx_HC(chnum)->HCINT) & USB_OTG_HCINT_NAK)�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?