12-08-2020, 10:10 PM
(This post was last modified: 12-09-2020, 08:52 PM by 0xF0.
Edit Reason: BDC says 1.1.0 not 1.0
)
Actually, looking at that dump, my guess is that the use of the Interface Association Descriptor is what might be tripping up these embedded hosts. Per the spec (https://www.usb.org/sites/default/files/...de_r10.pdf) :
I believe the reliance of the serial interface on this IAD is possibly the problem. The other interface coding actually looks correct (the device describes three interfaces, two of which are linked by the IAD and form the serial port, and the other interface is correctly describing a MIDI device.
So, things the NDLR is probably doing wrong or problematically for embedded hosts:
1. Not specifying itself as powered (unlikely to be a major problem, but it is a bug).
2. The use of the IAD descriptor in the serial port implementation (CDC version 1.2, rather than 1.1.0 as the BCD USB encodes) is likely to trip up a LOT of older (Full-speed only) embedded libraries which use version 1.0 of the class compliance protocols. IMO this should be removed and replaced with a single-interface CDC 1.0-compliant serial port implementation.
At worst, perhaps the IAD and CDC interfaces could be moved to the last two interfaces on the unit rather than the first two. This might give the MIDI interface parsers a chance to lock on correctly even if they abort parsing the rest of the descriptors. Worth a shot at least.
Edit: I think that iConnectivity should absolutely be ignoring descriptors they don't handle, and continue parsing interfaces until they see a MIDI one, though. This doesn't excuse their part of this, but it does indicate why it's not all their fault - NDLR should easily be hostable by any embedded USB host out there that follows the 1.0 specs or later, and the fact that it isn't is, fundamentally a bug on the NDLR, not anything else. Fortunately it looks easily fixable, although the team might have to give up or re-implement their precious serial port (but you know my thoughts on that, too: use JTAG/SWD for developer debugging and forget serial ports for that purpose, and use Sysex for the API, poof problem solved and you'll probably save some flash too).
Edit 2: Jesse, can you share with us the Teensy instructions you sent iConnectivity for building an identical-looking USB target device? I don't teensy but it might help some of those of us who do to do some parallel investigation. This is clearly an issue for a lot of your users here.
Quote:There exists a legacy issue for new devices that use the IAD (implying interface level binding to device drivers as opposed to device-level binding) when connected to systems where USB system software does not understand the IAD. Although the IAD will be ignored, the device may not work as expected because the USB system software will not properly bind the interfaces with drivers. (emphasis mine)
I believe the reliance of the serial interface on this IAD is possibly the problem. The other interface coding actually looks correct (the device describes three interfaces, two of which are linked by the IAD and form the serial port, and the other interface is correctly describing a MIDI device.
So, things the NDLR is probably doing wrong or problematically for embedded hosts:
1. Not specifying itself as powered (unlikely to be a major problem, but it is a bug).
2. The use of the IAD descriptor in the serial port implementation (CDC version 1.2, rather than 1.1.0 as the BCD USB encodes) is likely to trip up a LOT of older (Full-speed only) embedded libraries which use version 1.0 of the class compliance protocols. IMO this should be removed and replaced with a single-interface CDC 1.0-compliant serial port implementation.
At worst, perhaps the IAD and CDC interfaces could be moved to the last two interfaces on the unit rather than the first two. This might give the MIDI interface parsers a chance to lock on correctly even if they abort parsing the rest of the descriptors. Worth a shot at least.
Edit: I think that iConnectivity should absolutely be ignoring descriptors they don't handle, and continue parsing interfaces until they see a MIDI one, though. This doesn't excuse their part of this, but it does indicate why it's not all their fault - NDLR should easily be hostable by any embedded USB host out there that follows the 1.0 specs or later, and the fact that it isn't is, fundamentally a bug on the NDLR, not anything else. Fortunately it looks easily fixable, although the team might have to give up or re-implement their precious serial port (but you know my thoughts on that, too: use JTAG/SWD for developer debugging and forget serial ports for that purpose, and use Sysex for the API, poof problem solved and you'll probably save some flash too).
Edit 2: Jesse, can you share with us the Teensy instructions you sent iConnectivity for building an identical-looking USB target device? I don't teensy but it might help some of those of us who do to do some parallel investigation. This is clearly an issue for a lot of your users here.