spent the last week tearing my hair out trying to control a midi device through USB host using a Nucleo F767ZI. Whether this affects other boards I do not know.Using the STM USB Host library sending two messages back to back (example below. psuedocode as i'm at work ATM) midi.sendNoteOn(1,38,127); midi.sendNoteOn(1,38,128); enabling ep debugging there is a pause and and the ep state goes to not idle. what you have to do is something like midi.sendNoteOn(1,38,127); Thread::wait(1); midi.sendNoteOn(1,38,128); works, but waiting 1ms between midi messages destroys any notion of this being a useful project! underneath there is a call to bulkWrite with the blocking flag set, but I'm 100% sure it doesn't block. as well as this general message sending problem, it breaks multi part sysex messages as well. But first things first. the sysex function is COMPLETELY BROKEN. it has buffer overruns, the subsequent parts of multi part messages repeat the content of the first, ending of messages not aligned on 3 byte boundaries doesnt work. I think I fixed all this last night, but when I took out my debug printf code it stopped working with multi part messages. problem was again the lack of blocking on bulkWrite, placing a Thread::wait after the bulkWrite fixes the problem. I'll post a fixed version of that code when i get in tonight and some point later on, an updated HostMidi with support for virtual cables. but the question comes down to bulkWrite not blocking. I'm assuming it should as it has a block parameter. Is this broken just for this board or a generic problem? i'm not best qualified to fix the underlying problem, having very very little mbed experience up to now, so I'm looking into a solution with endpoint callbacks, but would rather see a proper fix and I'm more interested in writing my app than doing stuff at this level! If I can't get it fixed I'll just have to junk the idea of mbed and move to something which works.