Why don't the usb_examples in the SDK set up PinMux on USB-OTG1?

[EdSutter]

I'm kinda asking a question and answering it here, hoping that someone will confirm or correct it...

Context is an MIMX1060EVK building with arm-gcc...

I'm starting to do some work with USB, so I built and installed the usb_examples/usb_device_audio_generator/bm and it worked as expected (I think).   It looks like it has a small buffer of PCM that it just loops on, and when I connect my board's  OTG port (J9) to a Linux box, I can see the USB audio device and hear the audio loop.

So, I believe it is working as it should; however, I look at the code and I don't see anything that sets up the USB-OTG1 pins.  I know the data lines are dedicated, but the other three lines USB_OTG1_ID, USB_OTG1_PWR and USB_OTG_OC are all muxed, and none of the pins are re-configured out of their default (GPIO) mode.

I don't know much low-level USB stuff [yet], but from the looks of the schematic, it appears that these pins would only be of use if the port was actually running in true "on-the-go" mode...

The USB_OTG1_ID pin would be monitored, and if it is determined that the connected device is a slave, then USB_OTG1_PWR would be used to enable power to the interface and USB_OTG1_OC would be used to detect over-current.  So, given the limited nature of the example, it works because the three default (GPIO input) pin configurations are just harmless.  Does that make sense? 

[mjbcswitzerland]

Ed

What you write makes sense. A pure device doesn't use any of the other (non-dedicated) pins.

If you take an OTG example rather than a pure device example you will possibly find others then used.

USB1 HW on the 1060 EVK is OTG capable.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]