Cannot enter recovery mode on non-booting Colibri iMX6S

Technical Support
, , , ,
1

I’m using a modified version of BSP 2.8 on a Colibri iMX6S. I need to update the device tree to support a new version of our hardware, so I made the changes to the device tree, rebuilt it, and reflashed the module from an SD card with the new .dtb. After flashing the module, it fails to boot. When I cycle the power on the evaluation board, the following messages are printed to the serial console:

Industrial temperature grade DDR3 timings, 32bit bus width.
Trying to boot from MMC1

Industrial temperature grade DDR3 timings, 32bit bus width.

In the past, I’ve been able to use recovery mode when I’ve done something that causes the module to not boot. I performed the following steps to try to enter recovery mode:

  1. Power off the evaluation board
  2. Remove the SD card
  3. Short the indicated pins with a pair of tweezers
  4. Power on the board
  5. Wait six seconds
  6. Remove the tweezers

However, when I perform these steps, I still get the same output on the serial console, and lsusb does not report any devices with a VID of 15a2. I tried the exact same steps with another module that I have, a Colibri iMX6DL 512MB IT V1.0B, and I was able to enter recovery mode:

$> lsusb
Bus 002 Device 003: ID 0bda:0307 Realtek Semiconductor Corp. Card Reader
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 029: ID 15a2:0061 Freescale Semiconductor, Inc. i.MX 6Solo/6DualLite SystemOnChip in RecoveryMode
Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$> sudo ./update.sh -d
Colibri iMX6 rootfs detected
...

What else can I do to put the iMX6S into recovery mode? The datasheet mentions a JTAG interface in section 5.28, but it doesn’t mention if it can be used to reload the firmware or to force the module into recovery mode.

2

I assume you tried with the pads as described here, right?

And you made absolutely sure no SD card is plugged in, right?

In rare cases, you might need to use the pads as described here instead:

3

I was able to get into recovery mode using the information in the second link. Though that link says to wait a few seconds, I had to keep the pads shorted for about 25 seconds before the module entered recovery mode (I used for sec in {1..100}; do echo $sec; lsusb | grep 15a2; sleep 1; done to time it, and ran the command just before I powered on the evaluation board).

Thank you for your help! It would be useful to have information about those pads in the regular iMX recovery mode page in case others run into this problem.

4

It sounds strange. On iMX6 HW level it takes less than a second to enter recovery mode. So I assume something wrong with your setup. Have you tried another USB cable and/or another dev computer?

5

I did some more testing, and I found that I only have to keep the pads shorted for a few seconds after powering on the evaluation board, but it takes 20 to 25 seconds for the USB device (15a2:0061) to appear on my laptop, a 2019 MacBook Pro running macOS Catalina. Perhaps the delay in the USB device showing up is caused by the OS.

6

Oh! We never tested it on Mac OS. I’m surprised it works at all.

7

The USB device shows up on macOS, but macOS cannot run update.sh -d because that script runs imx_usb which is a Linux binary. Instead, I run the update script inside of a Linux VM.

Normally I’d be doing all of my development on my Linux workstation, but it is locked away in my office, and I’m working from home for the foreseeable future. Thankfully the Linux VM has worked well enough.

8

In the future, please do state clearly that you are running stuff in an unsupported VM configuration. Thanks!