USB MSD does not function properly on multiple targets

[Sissors]

Description

• Type: Bug
• Priority: Major

---

Bug

Target
KL25z, K64F, Arch Max

Toolchain:
Online compiler

USB MSD code does not result in a USB drive showing up. To verify both USB RAM disk code has been used: https://developer.mbed.org/users/Sissors/code/USBMSB_Ramdisk_kl25z/, and the standard USBMSD_SD example https://developer.mbed.org/users/samux/code/USBMSD_SD_HelloWorld_Mbed/docs/989ca460ad95/main_8cpp_source.html (updated where needed, in which case also in the read/write function the count argument needs to be added). For testing, both it is a matter of programming, plug in the MCU USB connector, and a drive should popup (of course when SD card is used that needs to actually be there, RAM disk needs nothing else).

Initially this appeared on a KL25z who is running some code already for years, and USB MSD is used to be able to modify configuration settings. Nothing was changed, yet it did not work anymore. I verified that code, USB RAM disk and SD file system myself, most on 2 PCs:
The original code on KL25z: Does not work
SD filesystem on KL25z and Arch Max (STM32F4): Does not work
RAM disk on KL25, K64F, Arch Max and LPC1768: Those first 3 it does not work, on the LPC1768 it works flawless, with identical code.

On all targets I have also used the USB Mouse example to verify the USB connection: works flawless on every target.

When it does not work it differs a bit how it doesn't work. Once in a while on Freescale MCUs the drive does show up, but when I try to open it in Windows explorer it returns an error. Sometimes a warning popups regarding broken USB device. Sometimes nothing happens. Sometimes in device manager it shows up the USB mass storage is there, but nothing in explorer. I tested this on my laptop, and some also on my desktop. @0xc0170 tested the RAM disk on Freescale and STM board, did not work. And someone else also helped me out by testing it on a K64F: did not work.

Now the weirdest part: This is both with latest version of the libs, and with old versions which 100% sure used to work perfectly fine. The original issue showed up with a board which was running the same code for years already, and twice a year or something got plugged into a laptop to update its time using USB MSD. So I would guess some Windows update might be related to it, but maybe it is something completely different.

So my first question: Can others reproduce this effect? And if yes, what is causing it?

[0xc0170]

cc @mmahadevan108

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-310

[0xc0170]

5877 should resolve this