iMXRT1010 and iMXRT1020 USB Audio example of composite device does not enumerate on Mac

[jeffrey_whitlat]

Using MCUXpresso 11.3.0 and SDK 2.6.0 for RT1010 and SDK 2.9.1 for RT1020 I have built the SDK example dev_composite_hid_audio_unified_bm on the evaluation boards for each MCU.  This example will build and function correctly on Windows 10.  I have tested on Windows on both debug and release builds.  Release builds I set anything other than -O0 (no optimization) and the USB audio device is not enumerated at all on Mac while working correctly on Windows 10 using the same firmware.

Interestingly enough the speaker only audio example in the SDK does work on both Windows and Mac.  The RT1020A silicon has errata regarding USB:Endpoint conflict issue in device mode which is unrelated to this optimization bug.

Seems like something is getting optimized out of the usb_device_ehci.c file as I can optimize -O3 the entire project except this file and things continue to work if I optimize this one file file -O0.  Otherwise the Mac ignores the device completely.

This seems to indicate that the code path being taken by the firmware is different between Windows and Mac on initial insertion of the USB cable.

A work-around is to just optimize usb_device_ehci.c -O0 when building release builds.  I will scrounge up a USB analyzer at some point, but wanted to report this bug.

[FelipeGarcia]

Hi Jeffrey,

I personally do not think that this is a bug, when optimization is enabled code can be reordered, assignments and initializations might be pulled out of loops so they are only executed once. Also, not volatile variables can be optimized and compiler will make assumptions about the content of the variables. Our USB drivers are not intended to handle high optimization levels so this type of issues are somehow within the expected.

It is good to know that you have found workaround for this and thank you for sharing it with the community.

Best regards,

Felipe

[jeffrey_whitlat]

Thank you for your response.  It is highly unusual in my humble opinion to ship code and never have tested it with optimizations turned on.  It is precisely the fact that optimizers can remove things like non-volatile variables (which by the way should be volatile if they are needed and due to the structure of the code might be removed) that we must always test both debug and release builds.

It is common practice to try and optimize code by size and/or speed before shipping.  As shipped this example cannot be compiled with optimizations turned on and continue to work, therefore I see it as a bug.  

While I respect your opinion that there is no such a thing as an optimization bug, I must respectfully disagree.

You are welcome for the work-around.  IMHO it should not be necessary however.

Cheers.

[jdavid75__]

You tell 'em Jeff!