Hello
I am using TM4C129ENCPDT processor with tirtos_tivac_2_16_01_14, TivaWare_C_Series-2.1.1.71b
I am running as a USB host and trying to set the line coding on a CDC device.
However I am finding that with some devices the USBHCDControlTransfer simply freezes at while(g_sUSBHEP0State.iState != eEP0StateIdle)
I have found that the g_sUSBHEP0State.iState is first set to eEP0StateSetupOUT
I then see the endpoint 0 interrupt for this packet and the 7 bytes for the LineCoding packet are sent out and the status set to eEP0StateStatusIN.
However after this I do not see another endpoint 0 interrupt and the code simply hangs waiting for the g_sUSBHEP0State.iState to return to idle.
I have confirmed from manufacturer data that I am sending the packet to the correct interface number (1) for the device and that I am using the correct data for the LineCoding information (7 bytes, 4 for baud rate, 1 for data bits, 1 for parity and 1 for stop bits). I even tried putting the values into a byte array to avoid any little endian / big endian issues.
// This is a Standard Device IN request. sSetupPacket.bmRequestType = USB_RTYPE_DIR_OUT | USB_RTYPE_CLASS | USB_RTYPE_INTERFACE; sSetupPacket.bRequest = 0x20; // Set Line Coding sSetupPacket.wValue = 0; // Always 0 sSetupPacket.wIndex = interface; // Interface number sSetupPacket.wLength = sizeof(LineConfig); // Set the config BaudRate = 115200; LineConfig[0] = (BaudRate >> 0) & 0xFF; LineConfig[1] = (BaudRate >> 8) & 0xFF; LineConfig[2] = (BaudRate >> 16) & 0xFF; LineConfig[3] = (BaudRate >> 24) & 0xFF; LineConfig[4] = 8; // 8 databits LineConfig[5] = USB_CDC_PARITY_NONE; // No parity LineConfig[6] = USB_CDC_STOP_BITS_1; // 1 stop bit // Send the command BytesSent = USBHCDControlTransfer(0, &sSetupPacket, psInst->psDevice, LineConfig, sizeof(LineConfig), psInst->psDevice->sDeviceDescriptor.bMaxPacketSize0);
However it freezes waiting for USBHCDControlTransfer which is waiting for a return to idle.
I would have expected that even if I accidently used the wrong interface number, the interrupt should have been received but the setting failed.
Should there actually be a timeout in this loop waiting for return to idle?