Can't really help, USB debugging is a pita. But as workaround you can try placing a USB (2.0) hub in between your KL25Z and PC.

I had exactly the opposite, it didn't work for me (unless with the USB hub in between), but it started working after I updated from windows 8 to 8.1, at which point I stopped looking into it. It definately is something in the relation between mbed code and the USB code on the PC, changes to either one can fix it, at least I also tried USB code from another platform for the USB and that worked fine when the mbed code didn't, but the mbed code worked fine on every other PC I have.

Also the firmware updater isn't designed by mbed, the firmware is (and that one already works for quite a while under windows 8.1), but the bootloader you get when plugging it in with reset pressed isn't from mbed.

Thanks. Yeah, I know the firmware in the KL25Z doesn't have anything to do with mbed. The problems I had with the firmware just made me suspect that 8.1 might also be the issue with the mbed code. My reasoning is that (a) 8.1 clearly made some changes on the Windows side of the connection that throws devices for a loop, and (b) I have to assume that the mbed code *has* worked for *someone* at some point, so the fact that it's completely non-functional for me makes me think it's something about my configuration. Ergo the 8.1 suspicion.

Quick follow-up. I tested the same code on a Windows 7 machine, and it works fine. It apparently really is an 8 or 8.1 issue. If anyone has any ideas about what's changed on the Windows driver side on 8/8.1, I'd appreciate whatever details you have.

I haven't had much luck debugging so far - having all the action in interrupt service routines seems to make it really twitchy about adding any sort of instrumentation. Everything I've tried so far in terms of instrumentation (including just turning on and off the on-board LEDs) seems to affect the results on the Windows side. I *think* what might be going on is that 8.1 is asking for an interface descriptor, and the mbed code has that part dummied out. I'm going to see if I can add the code to return an interface descriptor and see if that makes any difference.

Some more follow-up. The more I look into this, the stranger it gets. I've been tracing the Windows side with the Microsoft Message Analyzer. The results are extremely inconsistent, which is making me suspect this could be a reentrancy issue. I haven't found the culprit yet, but the Windows driver completes the protocol to different degrees on each connection, seemingly at random. It sometimes fails in the Get Full Configuration step, other times it makes it as far as asking for the Serial Number and Language strings. When Get Full Configuration fails, it usually fails with a parsing error on the Windows side, suggesting that the data packet was corrupted in transit. I think the definition of the packet is correct in the code, both from my own careful inspection of the source and from the fact that Get Full Configuration succeeds some percentage of the time. When one of the later steps fails, it seems to be because the transfer was not completed - the message log says that some number of bytes were requested and zero bytes were received.

It seems to me that there are three obvious possibilities.

One is that there's a reentrancy issue on the device side - presumably this could be triggered if Windows 8.1 is sending requests asynchronously such that a host-to-device request arrives while a device-to-host reply is pending. The mbed code uses a single static buffer (member 'transfer' of USBDevice) for both directions, so it seems possible to me that this is how the messages are getting corrupted. So far, it looks like the mbed code is correctly setting up all of the config responses that Windows is asking for, so clearly something is going wrong between the time the code sets up the messages and the time they're received on the Windows side.

Second is that Windows 8.1 is much tighter about timing than Win 7, so that it considers a request to have failed in too short a time for this device. This seems implausible - this device should be plenty fast and isn't busy with anything else, so it should be responding immediately.

Third is that the HAL has a bug in the low-level protocol handling. That could also have the effect of corrupting messages that are well-formed at the higher layers of the code. I haven't looked at that level yet.

I still don't know what the problem is in the software, but I finally found a workaround. The code works if I plug the device into a USB 2 port on my Win 8.1 machine rather than a USB 3 port. There are numerous notes on the Web about some devices being incompatible with Win 8.1 when plugged into a USB 3 port, although they're all targeted at end users trying to get devices working, so they don't have any information about what needs to be done on the device side to fix the problem. There's reportedly a new protocol element they added in the Win 8.1 drivers that's only used if the *port* supports USB 3, and whatever it is confuses some devices, evidently including ones based on the mbed USB Device stack. It would still be great to figure out exactly what the root cause is and fix it in the mbed USB Device code, but at least I have a working setup now if I plug the device into the right port.

I think I've found a solution!

See my answer to what seems to be the same question here:

http://mbed.org/questions/2599/Is-USBSerial-giving-problems-on-new-Hasw/#answer4609