USBDBG Communication Algorithm (Compact 2013)
10/16/2014
To create a platform-dependent device driver (PDD) for your platform, you, as the OEM developer, must build a PDD that communicates with the model device drivers (MDD). The MDD is compiled in a library and the source is not available. The following description of the MDD communication algorithm will help you create a PDD that communicates successfully with the MDD.
Initialization
When the MDD is started, it goes through the following initialization sequence.
The MDD calls the function UsbDbgPdd_Init, as shown in the following code.
UsbDbgPdd_Init(&m_mddInterface, &m_pddIfc, (USBDBG_DEVICE_DESCRIPTOR*) &m_deviceDesc);For each endpoint in the USB connection, the MDD calls UsbDbgPdd_Ioctl to get the endpoint’s maximum packet size.
The MDD calls UsbDbgPdd_Connect to start the USB attach and reset process.
The MDD waits up to 300 seconds for the protocol to initialize. The remote network driver interface specification (RNDIS) protocol is initialized when the RNDIS host on the development computer sends a message to set the packet filter to a nonzero value. The serial protocol is initialized when the serial host on the development computer sets the data terminal ready (DTR) signal to one with the SET_CONTROL_LINE_STATE constant.
Send Data
The MDD performs the following sequence of events to send data.
The MDD starts transferring data by using the following command.
UsbDbgPdd_SendData(epNum, pBuffer, cbTransferSize, USBDBG_MDD_TRANSFER_START);It then enters a loop to transmit additional packets. It checks to see if the last transmission is complete by using the following command.
UsbDbgPdd_EventHandler();If the previous transmission is complete, it sends more data.
UsbDbgPdd_SendData(epNum, pBuffer, cbTransferSize, 0);After all the data has been sent, it breaks out of the loop and cleans up.
If the data that was sent was an exact multiple of the maximum packet size, it sends a zero-length packet to signal that the transmission is complete. If the data is not an exact multiple, then the packet that is smaller than the endpoint’s maximum size signals the end of the transmission.
Receive Data
The MDD performs the following sequence of events when receiving data.
The MDD begins to receive data when the PDD calls the following function.
UsbDbgPdd_RecvData(epNum, NULL, cbTransferSize, USBDBG_MDD_TRANSFER_START, &transferStatus);In a loop, the MDD checks for packets by calling the following function.
UsbDbgPdd_EventHandler();When data is available, it receives it.
UsbDbgPdd_RecvData(epNum, pBuffer, cbBufSize, 0, &transferStatus);When the MDD receives a packet that is less than the buffer size or the data buffer is completely filled, it leaves the loop and cleans up.
It is the responsibility of the PDD to disable the receive first-in, first-out (FIFO) buffer when the transfer is complete. When the receive FIFO buffer is disabled, the PDD returns transferStatus = USBDBG_PDD_TRANSFER_COMPLETE to signal to the MDD that the transfer is complete .
Suspend and Resume
The USBDBG RNDIS supports suspend and resume operations. Suspend and resume functionality is not supported on an emulated serial connection.
On suspend, the OEM adaption layer (OAL) must call KITL IOCTLs to turn off kernel independent transport layer (KITL) transport. The PDD responds to the IOCTL_KITL_POWER_CALL I/O control by calling the UsbDbgPdd_SetPower function with the fPowerOff parameter set to FALSE. After the UsbDbgPdd_SetPower call is complete, the PDD can logically detach from the USB cable and remove the device from the bus.
On resume, the OAL must call IOCTL_KITL_POWER_CALL to turn on KITL transport. The PDD responds to the IOCTL_KITL_POWER_CALL I/O control by calling the UsbDbgPdd_SetPower function with the fPowerOff parameter set to TRUE. The PDD can then logically attach to the USB cable to reset the USB Debug connection. After the connection is enumerated, Platform Builder synchronizes with the device to reestablish KITL streams.
See Also
Concepts
USBDBG Communication Algorithm