- Removed target alias from the EXPORT_MAP in targets.py as it didn't work
- Added copies of the LPC4088 target exporters
- Fixed flag issue in the gcc toolchain
- Changed defines in eth USBDevice, rpt and rtos to handle
TARGET_LPC4088_DM
In the old K64F register .h file (same for K22F),
SIM_SOPT2_PLLFLLSEL_MASK was incorrectly set as a 1-bit field, like it
was in the KLXX devices, while it now is a 2-bit field. This has been
fixed in the current register maps, however the USB clock was set by
taking the entire mask, while only the first bit needs to be set.
This is now fixed by using the SHIFT definition, and should work also on
other Freescale targets (verified on K64, K22 and KL25)
The count argument in disk_read() and disk_write() is now passed to the
FATFileSystem instance. This allows more efficient disk drivers to be
written that can read and write multiple sectors at a time.
This change fixes a problem I've encountered using the Freescale KL25Z as a USB client device when attaching to a USB 3.0 port on a host PC. I've personally observed the problem on two PCs, one a Dell running Windows 8.1 and the other a custom-built Windows 7 machine with a Gigabyte mobo. Several other people on the Web have reported what appears to be the same problem. It even appears to happen with some Macs - so it's apparently not Windows-specific or Windows-version-specific. But it does seem to be USB 3.0 specific, and one report speculated that the common element is the Intel Haswell chip set on the host side.
The problem can be worked around by using USB 2.1 ports (many PCs have a mix of 2.1 and 3.0 port hardware) or by connecting a USB 2.1 hub between the device and host. I have USB 2.1 ports on both of my testing machines, and this solution does work for me. But I wanted to fix it at the software level if possible, so that my project would work for people who might only have USB 3.0 ports available.
I tracked down the problem to a timing issue that seems to cause the device and host to get out of sync with respect to flow direction on the USB connection during the initial handshake. It seems that the host can issue a CONTROL OUT token at a point where the client is trying to send the response for a previous CONTROL IN token. I found a note in some USB 3.0 reference material that this situation can occur, and that the client can resolve it by sending a zero-length ACK, which tells the host that the client isn't ready and that the host request should be repeated.
My fix sends a zero-length reply in USBDevice::controlOut() when the control flow error is detected, and also explicitly sends the pending CONTROL_IN packet. This appears to fix it reliably on my machine. I'm not entirely confident about the fix, though, since I don't feel I understand the USB protocol or the mbed code in enough depth. I'm submitting the change here in the hope that someone with a deeper knowledge of the mbed code can determine if this is a good fix, and if not can hopefully use it as the starting point for a better solution.
Note that I submitted the same pull request via the mbed source control system, but I was advised by another mbed user that I should also submit it directly on github. Apologies for any confusion caused by the redundant submissions.
[LPC1549] Added USBDevice support by va009039's code
[LPC1549] Fixed warnings by GCC toolchain and removed redundant code
[LPC11U68] Fixed warnings by GCC toolchain and removed redundant code
Added code to reset the device to the initial state when disconnect() is called. This prevents calls to configured() from returning true when the device has been disconnected.
Martin Kojtal
julbouln
Jeremy Brodt
Bogdan Marinescu
Clement Leger
Masao Hamanaka
Paul Staron
Anders Lindvall
Martin Olejar
Sissors
Bogdan Marinescu
AMANUMA Kazuhisa
bagbag
Paul Brook
Yihui Xiong
neilt6
mjrgh
Toyomasa Watarai