iMX7D second USB port not working

A second USB port on our custom carrier board isn’t working in WEC2013. I’m sure that when I first booted up with easy installer, both ports were working as I tried a mouse on them. Also on an Aster carrier board both ports are working. This is with another module though.

Is there some disabling of the port that may have occurred in the registry?

USB2 connected to pins 139 & 141 is working. USB1 connected to 143 & 145 isn’t working.

Having done an ABA test with the module in the Aster board it is probably our carrier board at fault. We dont have the OTG connector and have also removed the cable detect circuit. This leaves pin 137 floating. As far as I can see from the Aster board, 137 need to be pulled low when the OTG isn’t used.

Is this correct?

Dear @dnicholls,

Could you set below registry

“Order”=dword:15 “Class”=dword:0c
“HcdCapability”=dword:0 ;TODO
check how to re-enable

and delete


This will make OTG port as always a USB host, If you don’t need device functionality.


Default SODIMM 137 pin is used for USB cable detection, Set SODIMM 137 pin to Output and high and then verify host port is working?

Please let us know if it is not helping you.

Dear @dnicholls

In the default configuration Pin 137 is used to detect whether USB_1 (143/145) is used as a host or as a function. You are correct: to use it as a host (so you can connect a mouse or thumb drive), this pin needs to be low.

There’s several options you can try:

  1. Add a pull-down to this signal. Please measure the signal level - I know that some modules pull the USB related pins pretty strongly towards a mid voltage. I’m not sure whether the iMX7 is one of them.
  2. Use the GPIO Library (or the GpioConfig Tool for a test) to force pin 137 as output-high.
  3. If pin 137 is occupied otherwise in your hardware, you can change the pin number in the registry
  4. You can modify the registry to use USB1 as host-only (lose the ability to switch to client mode). For this, simply move all registry entries from [HKLM\Drivers\Builtin\USBOTG\Hcd] up one level to [HKLM\Drivers\Builtin\USBOTG]

With options 2-4 you can avoid a hardware redesign.

Regards, Andy

The registry change hasn’t worked and in fact stopped all of my USB operating! I did only have USB_OTG2, not USB_OTG1. I therefore renamed which has probably cause some upset.

After rebooting, [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\USBOTG] has reappeared in the registry and can now not be deleted with the message "Can't query key 'Drivers\BuiltIn\USBOTG'"

Also USB_OTG2 reappeared after a reboot. The registry was saved before resboot.

Setting the pin 137 as output also didn’t seem to help.

We are able to do a HW mod to connect the pin 137 to high or low, I just need to confirm that this should work?

Ok, using the GpioConfig Tool has worked to prove the pin needs to be output-high and the lower USB port now works with a mouse. Is there an inversion of the pin because physically I think it needs to be pulled to 0V rather than high, and this is what you said as well?

Dear @dnicholls
I’m afraid I don’t have an explanation for the inversion. I tested the settings on an Evaluation Board, and for me the polarity was as expected.
Regards, Andy

A follow up to this, we have a second rev of our base board where we pull via a 10K the DET pin 137 to ground. This fixes the USB but this seems to have the side affect that on reset pin 21, for the UART_C_TXD is now configured for something related to the OTG. We checked this with the GPIO tool. Is this a bug in the OS or is there some other feature that is being introduced?

Ah, I think this has already been answered in UARTC not working - Technical Support - Toradex Community

HI @dnicholls

Is the issue solved now?

Sort of, I can modify the registry to either make the AltFn=0 or delete it altogeter; these both work. But I prefer to have the correct setting in my OS build so I have put the following in platform.reg, but this seems to get overwritten in the resulting OS build.


Ok, found it. My search wasn’t working properly so it is a later entry in the same platform.reg!

Perfect that the issue is solved.
Thanks for the feedback.

Best regards,