USB wiring Colibri IMX6ULL Wifi

We use the Colibri IMX6ULL on a custom carrier board. Our goal is to use the USB OTG port as a USB host to connect a USB→ LAN converter (Microchip LAN9500). We notice that the link is unstable in our current implementation. To test the network link, we use iperf3.

We tried the same test using the Iris V2 carrier board and it works fine.

Attached is our wiring schematics on our board, is there anything that seems wrong? We wired pin 127 (USB ID) to ground since we do not use the dynamic host/client OTG function and we provide the VBUS from an external power supply. The ground potential is shared between the 3V3 powering the Colibri and the 5V of the VBUS.

I also attach the relevant part of the device tree:

Device tree:

#include "imx6ull-colibri-wifi.dtsi"

/ {
	model = "Toradex Colibri iMX6ULL 512MB";
	compatible = "xxxx,colibri-imx6ull-wifi",
		     "toradex,colibri-imx6ull",
		     "fsl,imx6ull";

    extcon_usbc_det: usbc_det {
        compatible = "linux,extcon-usb-gpio";
        debounce = <25>;
        id-gpio = <&gpio5 2 GPIO_ACTIVE_HIGH>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_snvs_usbc_det>;
    };
};
&usbotg1 {
    extcon = <&extcon_usbc_det &extcon_usbc_det>;
	vbus-supply = <&reg_usbh_vbus>;
	status = "okay";
};

My questions are:

  • Is there anything in the wiring that looks weird?
  • Is the device tree correct?
  • What are good practice in terms of connecting ground and cable shields ? In our carrier board, they are simply tied together

Thank you

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


Looking at your USB OTG implementation for the Colibri iMX6ULL, I can see several issues that need addressing. Let me help you identify the problems and provide proper guidance based on the official Toradex carrier board design documentation.

Hardware Issues

1. ID Pin Configuration

Your wiring shows pin 127 (USB_ID) tied directly to ground. This is problematic for several reasons:

  • The ID pin requires proper pull-up/pull-down configuration for reliable OTG detection (1)
  • For host-only operation, the ID pin should be pulled to ground through a proper resistor, not directly tied (1)

2. Over-current Protection Missing

Your schematic lacks proper over-current protection, which is required for USB-compliant design (2). The documentation states: “A USB-compliant design needs to detect over-current on the provided bus power output. The output rail needs to be turned off if an over-current condition occurs” (2).

3. ESD Protection

Your design appears to be missing ESD protection diodes on the USB signals (3). The documentation clearly states: “If the USB signals are externally available, ESD protection diodes must be placed on all USB signals” (3).

4. Common Mode Choke Missing

For EMI compliance, you need a common mode choke on the USB 2.0 data signals (3). The documentation specifies: “The USB signals additionally require a common mode choke for passing EMI testing. Use common mode chokes that are specified for High-speed USB 2.0” (3).

Device Tree Issues

Your device tree configuration has several problems:

1. Incorrect GPIO Configuration

The ID pin configuration in your device tree doesn’t match the hardware wiring. If you’re hardwiring the ID pin to ground for host-only operation, you shouldn’t need the extcon configuration.

2. Missing Pull-up Configuration

For the over-current signal, you need a pull-up resistor configuration in the device tree (2).

Recommended Solutions

Hardware Modifications:

  1. Add proper ID pin pull-down: Use a pull-down resistor (typically 100kΩ) instead of direct ground connection
  2. Implement over-current protection: Add a power switch IC with over-current detection
  3. Add ESD protection: Install USB-compliant TVS diodes on all USB signals
  4. Add common mode choke: Install a high-speed USB 2.0 compatible common mode choke

Device Tree Modifications:

For host-only operation, consider simplifying your device tree similar to the client-only reference, but configured for host mode (4).

Ground and Shield Practices

Regarding your question about ground and cable shields: connecting them together is generally acceptable, but ensure proper grounding hierarchy and consider EMI implications. The shield should provide a clean return path without creating ground loops.

Next Steps

To provide more specific guidance, could you clarify:

  • Which OS version are you running on your Colibri iMX6ULL?
  • Are you using Torizon OS, Yocto BSP, or another Linux distribution?

You can get this information using the tdx-info command as described here.

The instability you’re experiencing is likely due to the combination of missing EMI filtering (common mode choke), inadequate ESD protection, and improper ID pin handling. These issues can cause signal integrity problems that manifest as intermittent connectivity issues, especially under network load testing like iperf3.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Replying to AI here…

Hardware points

  1. Ok, I can add a pull down to ground.
  2. Noted. In the reference design and the manual of the module, the OC detection (pin 139) is an output pulled up to 3.3V. Is that correct, and should I also use a pull up?
  3. ESD protection is implemented with USBULC6-2M6 diodes
  4. Common mode choke is implemented through DLP31SN121ML2L

Device tree

  1. Ok, but I share the device tree with another module that supports host/client swapping. THe current implementation should not hurt
  2. I will implement a pull up resistor in hardware for the OC pin

Excellent feedback! Let me clarify the specific points about the Colibri iMX6ULL USB implementation based on the official documentation.

Hardware Clarifications

2. Over-Current Detection Pin Configuration

You’re absolutely correct about the over-current detection. According to the Colibri iMX6ULL datasheet, the USB Host Over-Current Detect pin (pin 131, SNVS_TAMPER5, gpio5.IO[5]) is indeed an input that requires a pull-up resistor (1). The documentation states: “USB overcurrent, this pin can Signal an overcurrent condition in the USB supply” (1).

So yes, you should implement a pull-up resistor to 3.3V on this pin, as it’s an input to the module that detects over-current conditions from your external power management circuitry.

3. & 4. ESD Protection and Common Mode Choke

Good to hear you already have these implemented:

  • USBULC6-2M6: This is appropriate for USB 2.0 ESD protection
  • DLP31SN121ML2L: This should provide the necessary common mode filtering for EMI compliance

USB Power Control Implementation

For the Colibri iMX6ULL, you’ll also need to implement the USB Host Power Enable functionality. The module provides pin 129 (GPIO1_IO02, usb.OTG2_PWR) as “USB Host Power Enable” which “enables the external USB voltage supply” (1).

Your external power management circuit should:

  1. Be controlled by the power enable signal (pin 129)
  2. Provide over-current detection feedback to pin 131
  3. Include proper pull-up on the over-current detection pin (3.3V)

Device Tree Considerations

Your current device tree approach should work fine for shared configurations. The extcon USB GPIO detection can coexist with hardware-strapped configurations, though it may be redundant if you’re hardwiring for host-only operation.

Recommended Next Steps

  1. Add pull-down resistor to the ID pin (typically 100kΩ to ground)
  2. Add pull-up resistor to the over-current detection pin (typically 4.7kΩ to 3.3V)
  3. Verify your power management circuit responds properly to the enable signal and provides over-current feedback

The combination of proper pull-up/pull-down resistors, existing ESD protection, and common mode choke should resolve the stability issues you’re experiencing with the LAN9500 adapter.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

However, none of this seems to explain the unstable connection. In case the issue I am seeing.

Can an actual person look into this?

Hi @thomasb!

Unfortunately, we currently don’t have the availability to review schematics or device tree overlays for custom carrier boards.

That said, I recommend checking our Partner Network, where you will find partners with the necessary expertise to help you with the custom board and to accelerate your project.

Best regards.