┬ÁTasker Forum > USB

USB on Windows 10



I obviously have a Windows 10 driver problem with my USB serial interface to my MK64 processor. I am wondering if you have experienced anything like this before.

When I connect my MK64 board via USB to a certain Windows 10 PC, the USB port is unreliable at best. I hear the Window's Chime when the MK64 is connected and the Device Manager shows the COM3 port connected. However, neither TeraTerm or Putty is able to connect for 10-15 seconds. Once connected, the menu interface seems to work just fine for a while then it hangs. The MK64 is not locked up or resetting. But, at this point, the port is unusable. Sometimes unplugging and plugging back in the cable from the PC to the MK64 frees up the port to work again.

I have other Windows 10 machines that work perfectly with the same MK64 device and same cable.

I have unloaded the Windows driver for the USB device and restarted the machine. Problem persists. This PC is a Dell Insperion or something like that built in 2018. A little old but still working well in all other aspects besides USB serial. No problems printing via USB. No problems with keyboard or mouse activity.




Here is the USBPcap log from Wireshark, if this helps.



Hi Phil

Some time in June 2021 I had an experience with USB-MSD that would not operate well although the code is several years old and hadn't behaved like this before. With Windows 10 and possibly after a Windows update.

My feeling is that something has been sped up in the enumeration/initialisation and what I saw was that set-ups with data were sent while previous handshakes had no yet completely terminated (queued) and what would happen is that the receiver in the HW would lose synch with the data toggling and drop a reception frame believing its data toggle was incorrect. This causes the host to wait maybe 10..15s and then reset and re-enumerate where is would often then work.

To (hopefully) resolve this 'race-state' I added a modification to kinetis_USB_FS_OTG.h as follows:

    07.06.2021 Resynchronise data buffers when sending status stage to ensure no race state on subsequent SETUP reception+ DATA {14}

If you have access to this (it is in branch V2.0.0 of the GIT repository) you may find that it solves the issue - I haven't seen it since but haven't used USB device on the Kinetis a great deal since then.

This is the actual modification that you could build in otherwise, in fnProcessInput():

    switch (fnUSB_handle_frame(ucFrameType, (unsigned char *)ptUSB_BD_rx->ptrUSB_BD_Data, iEndpoint_ref, ptrUSB_HW)) { // generic handler routine
    case TERMINATE_ZERO_DATA:                                            // send zero data packet to complete status stage of control transfer
        if (iEndpoint_ref == 0) {                                        // {14} resynchronise data buffers when sending status stage
            if (&ptEndpointBD->usb_bd_rx_even == ptUSB_BD_rx) {
                ptEndpointBD->usb_bd_rx_even.ulUSB_BDControl |= (DATA_1);
                ptEndpointBD->usb_bd_rx_odd.ulUSB_BDControl &= ~DATA_1;
                ptEndpointBD->usb_bd_rx_odd.ulUSB_BDControl |= OWN;
            else {
                ptEndpointBD->usb_bd_rx_odd.ulUSB_BDControl |= (DATA_1);
                ptEndpointBD->usb_bd_rx_even.ulUSB_BDControl &= ~DATA_1;
                ptEndpointBD->usb_bd_rx_even.ulUSB_BDControl |= OWN;
        *ptrUSB_HW->ptr_ulUSB_BDControl = (OWN | ptrUSB_HW->ptrEndpoint->ulNextTxData0); // transmit a zero data packet on control endpoint
        _SIM_USB(0, USB_SIM_TX, iEndpoint_ref, ptrUSB_HW);
        ptrUSB_HW->ptrEndpoint->ulNextTxData0 ^= DATA_1;                 // toggle the data packet

It utilises the point when it is sending a zero frame status stage (just before the host will be allowed to send further sequences) to reset the rx toggle buffer to be sure that they are both ready to receive data 0 and data 1 tokens Previously there was a very small window where the data toggle may not have been correct in both and when the host very quickly sends a following setup and data to the two one may not be correct and thus the data dropped (since the HW thinks it is a repetition it ACKs it though, so the host thinks all is good but times out waiting for the actual response).




Thank you. However, this did not resolve the problem.  I will come back to this later and step through the code and report.  It is also obvious that I need to update my copy of uTasker.

I will report back once I get my copy updated to the latest version of uTasker and I have walked through the code.

Best regards,



[0] Message Index

Go to full version