KL25Z fixes for USB 3.0 hosts and sleep/resume interrupt handling

This is a bundle of two changes I made for the KL25Z.

The first is a simple addition to handle sleep/resume interrupts with calls to suspendStateChanged(). This appears to be the intended behavior, and is implemented in the corresponding code for other devices, so I think its omission in the official library code was just an oversight. The changes look simple enough and work reliably in my testing.

I'm less confident about the second change, which I added to fix the KL25Z for USB 3.0 hosts. This is the change in USBDevice::controlOut(), which I #ifdef'd with KL25Z tags, although it might work generically. There's an apparently known problem with the mbed KL25Z code when used with USB 3.0 ports on hosts based on Intel Haswell chip sets - this reportedly affects some Macs, and I've observed it on two separate Windows machines (a Dell running Windows 8 and a custom-built Win 7 machine with a Gigabyte mobo). With the affected hardware, the USB connection to the KL25Z fails during the initial handshake. The failure is reliably repeatable but happens at unpredictable points in the handshake, so it must be a timing issue. The problem appears to be that the host side sends a CONTROL OUT token before client has had a chance to respond to a previous CONTROL IN token. The mbed USB stack detects this in controlOut() and returns an error, which makes the higher layers of code do a STALL on the connection. The host interprets the stall as a connection failure and disables the device. I'm not a USB expert, but some USB reference material I found said that a valid response in this kind of situation is for the client to send a zero-length ACK to tell the host that it's not ready for the CONTROL OUT. My change sends a zero-length reply, and also explicitly sends the pending CONTROL IN packet to the host. In my testing this seems to entirely clear up the problem. But I don't feel I understand either the USB protocol itself or the mbed USB stack in enough depth to know if this is really the right solution, or if it just happens to work on my particular hardware, or if it just reduces the chances of the underlying problem and I've just been lucky so far. I've been testing this for a few days without seeing any recurrence of the problem, so I *think* it's a valid fix, but I'm still cautious about it because I fell like it was a lucky shot in the dark. Hopefully one of the official library developers who knows the code will be able to determine if this is the right solution.

Last updated: 17 Mar 2017

55 124

Mike R / USBDevice

USB device stack, with KL25Z fixes for USB 3.0 hosts and sleep/resume interrupt handling device, USB