Currently, I’m evaluating the Colibri T20 (1.1 C) on Iris (1.1 A) base board, and I’m facing some problems with the UART-A (X13).
I tried to connect to the target board from my linux (arch) host system over UART, to flash new system images (Colibri_T20_LinuxImageV2.6) into the on-board flash, after executing u-boot with the provided USB flasher (tegrarcm / with “sudo ./update.sh -r 512 -v V1_1 -b nand -d”).
In recovery mode (jumper JP1 set) I can load and run u-boot as it seems, but when I try to connect to the serial console, I only can see “garbage characters” coming in on the console.
I’ve tried this with 5V Sparkfun FTDI breakout board, by connecting only RX/TX, and in a second test, also with all “null modem” wires hooked up. I’ve assumed 115200/8-N-1 (“picocom --baud 115200 /dev/ttyUSB0”), but tested it with other settings as well, but with no luck yet.
The behavior is this: I can see an infinite stream of scrabled characters after power cycling the board. With all null modem lines connected, it stops after loading u-boot (assumingly). Sending keystrokes has no effect… either my USB-to-serial hardware is broken (unlikely, it works in other situations), the connections are wrong or the there’s problem on the Iris/Colibri board. No idea yet…
Any suggestions would be appreciated a lot.
EDIT: The board itself works, before trying to update the OS, it ran an older version of Windows CE without any problems whatsoever.
Before we go deeper into this one common mistake is to use an adapter which uses CMOS signal levels, i.e. 0V is space and 3.3V is mark.
The Iris board has a RS232 transceiver which provides +3…+15V for space and -3V…-15V for mark.
So you would need an adapter which on top of the USB to UART chip also has a RS232 transceiver to be electrical compatible.
Additonally you need an adapter to the pinheader X22 as specified here.
Thank you for the fast answer, it seems to be in fact a problem the TTL voltage levels.
Additonally you need an adapter to the pinheader X22 as specified here.
The X13 (UART-A) pinheader, right? That’s where I hooked up the jumper wires to the FTDI breakout right now, because we don’t have a proper RS232 to USB device here.
So, it would be possible to use a MAX232 or similar IC to shift the voltage levels from TTL to RS232. That’s something I could possibly try today, otherwise I have to order new hardware.
Out of curiosity, since I’m more a software person:
Would it be possible to “bypass” the RS232 transceiver on your board (IC4A pin 13 (TxD) / pin 16 (RxD), found right before in the Iris schematics), and solder “temporary patch cables” right in front of it? – I have not yet looked into the details about this yet, but assume 3.3V TTL levels coming from the Colibri module…
Is it enough to connect just the RxD/TxD/GND line? - RTS/CTS (Flow control) and DTR/DSR can be left unconnected?
I’d really like to try out the linux images on the Colibri T20 to see if I can handle the environment for a planned project, but as it seems there is now way around using the bootloader console to update the OS images right, there’s no direct boot from SD card? - Which is fine, since we need to have a debug console anyway…
Sorry about that, I meant X13. (The X22 comes from the Ixora board)
Would it be possible to “bypass” the RS232 transceiver on your board.
Yes. Actually you can switch IC4 off with the FORCEOFF# pin connected to SODIMM_102.
The UART signals on 3.3V TTL levels can be accessed on connector X16.
Is it enough to connect just the RxD/TxD/GND line?
In U-Boot yes.
In Linux probably yes. HW handshaking is switched on here, so the CTS input could inhibit sending but at least with the IC4 active the CTS input defaults to allow sending when left open.
but as it seems there is now way around using the bootloader console to update the OS images
That is correct.
(You could make a custom U-Boot which does stuff differently should your project require that for production code.)
Out of curiosity I’ve removed IC4 (SN65C3243 / RS232 transceiver) completely, and put wire bridges to all the UART-A lines going to the original X13 pin header. This was a mistake! All the TTL levels are also accessible on the large Extension Connector (X16), like you said… oh well. - The RS232 interface was of no use in our case, so it’s not really a problem.
Now it is possible to read from the UART-A! But somehow not write to it. Keystrokes are not echoed back in the U-Boot console, but I can see the TX line moving, so I suspect that there’s still something wrong with my hardware setup. - I’ve connected CTS/RTS as well (crossed), just to be sure that it has nothing to do with the HW handshaking. - That’s what I see after boot / using the update.sh script, in recovery mode:
It finally works now! My FTDI breakout must have been damaged while experimenting with the board (TX led still blinking, but TxD line voltage actually not changing), and I had to replace it.
