Debugging i.MX6 ULL USB ROM Bootloader

[MichaelTB]

This is on a i.MX6 ULL processor.

I am trying to get the USB ROM Bootloader to work reliably on a set of prototype boards I am working on. I have some boards that will properly enumerate on the USB bus and be detected in Windows while other boards will not be detected.

This looks somewhat like https://community.nxp.com/t5/i-MX-Processors/imx6ull-HID-detection-issue/m-p/904960 .

I either get the "Freescale SE Blank 6ULL" detected almost immediately in Windows, or it goes for about 10 seconds before saying the device is not recognized. The boards behave similarly in Linux - I can follow (like tail -f) dmesg and see a device detected on the bus but then fail to communicate properly.

In a test a few months ago I turned the OTG1 bus around so it was a host instead of being the bootloader device. That board that had trouble connecting as a bootloader had no trouble playing host to a USB flash drive that U-Boot could detect.

I also have the same boards with bootloader difficulty successfully able to play host to the USB port of a cellular modem on the same board. The modem communication and the USB flash drive test strongly tell me that the USB PHY is properly powered and that the clocking of the processor is working well.

As of today, I now have USB bus captures generated by a Total Phase Beagle USB 480 analyzer that show the behavior on a good and on a bad board. I have attached those files here.

Can anyone spot where the connection process is going wrong based on the capture files?

Are there any windows available into the ROM bootloader's black box, such as status messages printed out to a UART?

Thank you,

-Michael

[jamesbone]

I think you need to review the schematics to see if the Power supply of VBUS it is correctly apply all the time, or sometimes the voltage it is not power up at the same time.  Since the EVK it is working as expected, it would be good to check schematics to see whats different

[MichaelTB]

I have attached a few oscilloscope captures here.

First, the basic board powerup. Yellow is the input voltage from a DC adapter to the board. Blue is the 3.3V supply connected to VDD_HIGH_IN and VDD_SNVS_IN. Purple is 1.35V for VDD_SOC_IN. Green, shown one division higher, is the voltage at USB_OTG1_VBUS, the same port where USB is connected to my computer. You can see that USB_OTG1_VBUS is solid at a touch over 5V the entire time of powerup.

Then I have a capture that shows the POR_B signal (green) which is driven by a Texas Instruments TPS3825-33 reset supervisor. The time between VDD_SOC_IN rising and POR_B going high is 172ms.

There is a brief time that POR_B (green) is rising with the 3.3V supply, but it goes low once the reset supervisor has enough voltage to operate. That is shown here, zoomed in from the previous capture.

With regards to BOOT_MODE[1:0] that should permit getting into serial download mode...

I have probed BOOT_MODE0 (green) and found it to be greater than 3V as long as the 3.3V rail is powered up. Sometime right after 3.3V reaches its maximum, something is applying a weak pull-down to BOOT_MODE0 that can't override the 10K pullup to 3.3V that my board has. 3.0V should be well above the VIH (0.7 * OVDD) for IO.

BOOT_MODE1 (green) is more straightforward - I have that stuck at GND directly through a switch. It stays at 0V:

We have recently obtained AN12853 "i.MX ROMs Log Events" from our distributor FAE and are working through it to see if that provides some insights on why we can't get to serial download mode.

-Michael

[MichaelTB]

I performed a capture of the ULL Eval Board (700-29364 Rev A + 700-28616 Rev A1 / SCH-29364 Rev A1 + SCH-28616 Rev C3) attaching to my computer (successfully) as "SE Blank 6ULL". The Total Phase Data Center file and screenshot of the capture are attached here.

[MichaelTB]

Here are images of the beginning of the captures from the Total Phase software in case it is enough to start providing clues (without registering and installing that software). The good board moves right along into getting various descriptors, but the bad board just has a bunch of apparent timeouts and never moves on to those stages, instead appearing to have a bunch of timeouts.

-Michael