10 years, 4 months ago.

I've been running into the same problem, on Windows 7 and 8 PCs, not Macs. The problem is similar to what you describe - it occurs when plugging the device into USB 3 ports, but not USB 2 ports.

I spent a while tracing through the USB message logs and instrumenting the mbed USB code, and I tracked down the problem to a handshake issue. I don't quite fully understand the protocol details, but what seems to be happening is that the device gets into a state where it thinks it's in DEVICE_TO_HOST mode at a point where it's trying to respond to one of the configuration messages. I think it might be timing related, because it's sporadic - it occurs with no apparent pattern at different points in the configuration handshake. The probability of the problem is high enough that it occurs with certainty within the first 5 or so message exchanges, but it sometimes occurs on the SET ADDRESS, sometimes on the GET FULL CONFIGURATION, and sometimes when the PC side stack starts asking for the configuration strings (product name, languages, etc). I suppose it's fortunate that the probability of failure on any given message is so high, since otherwise it would probably be even more maddening in that it would successfully connect some percentage of the time and only fail sporadically. As it is, I was motivated to try to fix it and not just chalk it up to gremlins!

As I said, I don't quite understand *why* the failure is occurring, or what's different in the USB protocol versions that triggers it only on USB 3 ports, but after trying a number of ad hoc solutions, I've come up with something that seems to be working quite reliably for me. In USBDevice/USBDevice/USBDevice.cpp (yes, that's a cpp file called USBDevice within a folder called USBDevice within the library called USBDevice :)), find the routine bool USBDevice::controlOut(void) at around line 181, and make the following change (added code shown with "+" marks):

bool USBDevice::controlOut(void) { /* Control transfer data OUT stage */ uint8_t buffer[MAX_PACKET_SIZE_EP0]; uint32_t packetSize;

/* Check we should be transferring data OUT */ if (transfer.direction != HOST_TO_DEVICE) { + controlIn(); + if (transfer.direction != HOST_TO_DEVICE) return false; }

/* Read from endpoint */ packetSize = EP0getReadResult(buffer);

This is the kind of stab-in-the-dark, "it seems to work but I'm not sure why" fix that I normally really hate. I really prefer to thoroughly understand the nature of the bug so that I can have confidence in the fix. But I've found it awfully overwhelming to try to learn enough about USB itself, the KL25Z USB hardware, and the mbed USB stack to truly understand what's going on, plus the debugging environment is awfully opaque given that Windows device drivers are half of the equation and a headless microcontroller is the other half.

If this fix works for you, let me know - it would make me more confident about it. Or if anyone understands the mbed code and USB protocols well enough to know if and why this fix *should* work, that would be good to hear about as well!

bool USBDevice::controlOut(void)
{
    /* Control transfer data OUT stage */
    uint8_t buffer[MAX_PACKET_SIZE_EP0];
    uint32_t packetSize;

    /* Check we should be transferring data OUT */
    if (transfer.direction != HOST_TO_DEVICE)
    {
+        controlIn();
+        if (transfer.direction != HOST_TO_DEVICE)
            return false;
    }

10 years, 6 months ago.

Is this issue being actively investigated? If not, I can take a look over the next couple of days. I think I have everything here to reproduce and debug the issue that Lars is hitting but I don't want to duplicate the effort of others.

-Adam

10 years, 9 months ago.

Lars,

Something you can try is grab a USB2 (preferably) USB hub. Put it between your KL25Z and your Mac and see if it works.

I have a windows Asus laptop, with only USB3 ports, and it doesn't work for me. With USB hub in between it works fine. I logged USB traffic on my laptop, and it can be summarized as pretty much no traffic whatsoever without the usb hub. To rule out USB CDC compliancy you can try for example USB mouse code, but for me it is all the same.

Now after ignoring it a couple of months I have a reason again to look at it, so few days back I asked guy from http://mcuoneclipse.com/2013/08/01/using-the-frdm-kl25z-as-a-usb-mouse-device/ if he could send me a binary of his code, since that was made with a completely different USB stack. That way I could rule out if the KL25Z itself can't handle USB3, or if for example the PCB connection isn't great, which could be a problem on some USB chipsets and not on others. Now that code besides bricking my mbed (really don't set the reset pin as GPIO, I managed to unbrick it again, but with mbed it is not intended :P), also showed that it worked perfectly fine.

So I am planning in the coming days/weeks to try to figure out where it goes wrong. The problem is that while I have reasonable amounts of experience with regular uC programming, debugging a USB stack is a whole different game.

What is related, the K20 interface IC uses the same peripheral (well maybe different revision, but close enough). That one does work fine. Maybe someone who worked on the CMSIS-DAP code knows what is different between them? (Besides that they are completely different code bases).

10 years, 8 months ago.

Hi Lars,

I am a bit confused about this bug report, so could you please give us a complete set of steps to reproduce the issue? Also, were you able to reproduce this issue on anything else than a Mac?

Thanks, Bogdan