Garbage characters when trying to access Colibri iMX6 bootloader

Just got a couple of Colibri iMX6 modules and Iris carrier boards and I’m trying to get into the bootloader following the method specified here: Bootloader Menu | Toradex Developer Center

This is what I get


I’ve also tried this on RealTerm and TeraTerm, same results.

During a standard boot, I get the same garbage up until a certain point in the boot process and everything seems fine. Attached is a log of the terminal during a standard boot up to the login.
log text

I’m using a USB to Serial adapter ( Voltage levels on a scope, measured on the X13 pins, is -8v to +8v.

There were a couple of similar questions here, but those seemed to have been caused by improper 3.3v levels.

Any idea what could be going on here? Thanks in advance.

1 Like


This looks strange. The kernel does not change anything on the UART around the time when intelligible strings appear.

To me it looks like you have an unreliable connection somewhere. An other reason could be that another signal can influence the TX signal.

How did you connect your serial adapter to Iris X13?
Is it possible that this makes somehow unreliable contact?

Did you connect anything to the X16 (The UART signals on the CMOS level side are accessible there)?

Are you able to send characters?
e.g. does the boot stop in U-Boot when repeatedly press a key after reset/power up?
If yes, and you wait a while do you get U-Boot output when you press return?
e.g. can you login to Linux?

Nothing connected to X16.

Pressing a key seems to stop the boot but the strings remain unintelligible.

I eventually just switched over to a computer with a proper COM port and everything was fine.
There might have been an issue with the USB-to-Serial adapter (I don’t have another one to compare to, so can’t really verify that).


Have you check the ground cable and if the connection speed is correct (the default is 115200 kbps)?

I faced the same issue and figured out that the ground cable connected wrongly.

1 Like

What exact hardware and software versions of things are you talking about?

1 Like

I had the same problem,
the problem is that the serial cable in the carrier board and the serial adapter USB are both configured as a HOST.
I had to switch the TXD and RXD lines, and all the output lines from the carrier board must be disconnected.

The DTR and RTS lines are outputs, and they are connected to RTS and DTR to the USB adapter, (not switched).

When the bootloader is starting, the line drops to GND, then is doing a short circuit, then the voltage in the USB adapter drops, beause of this, the RXD has a low voltage and then receiving garbage. After waiting for a key press, the DTR is pushed to high level, then the short circuit disapears.

I had to disconnect the lines DTR and RTS, and all works fine.

Yes, all UART signals on any of our hardware are always described from the module point of view. So an RxD is where data is received, TxD where data is sent and the same applies to any hand shaking signals. There is absolutely nothing special about that at all.

Hi, I had the same issue with my Iris carrier board v1.1B and seems to be a hardware problem with IC4 driver (SN65C3243) which doesn’t work properly with some serial-to-USB adapters attached.
Only the output channels are affected losing its correct rectangular +5/-5V wave when the characters are sent.
I have solved this issue by replacing the ic and increasing the switching capacitors from 0.1 to 0.22uF which are in connection with the internal charge pumps.
In the first instance I have used the mirrored TTL UART_A from X16 and a converter based on the FTDI FT232R chip. But this port (X16-27,28) could not be used completely because the RX pin is locked by IC4 driver with the configuration in boot config block which it was inaccessible yet.
This is a missing of the Iris carrier board because if the X13 UART_A port is damaged the user can not access the boot config block to change the booting port. A jumper switch is good to be added on IC4-pin22 to FORCEOFF the chip and release UART_A to be used on extension X16. Kind Regards,Stefan

Dear @ancontech,

thank you very much for sharing your experience with us. Do you think you had to replace the IC because you somehow damaged it?
Regarding the capacitors, we have followed what is recommended on the datasheet of this device. It is a bit strange that you had to replace these capacitors to have it working fine. This might be related to the USB adapter used.

Regarding the use of port X16, yes, this is a chicken and egg situation. The force-off jumper has not been placed on Iris because this product main target is not to be used as a development platform, but to be deployed in final products. The best approach, in a similar situation, is to insert the Colibri module in the Colibri Evaluation Board and configure the software.

I hope this helps, please don’t hesitate to use again the community if needed.