Connecting to DevTerm A06 over USB-UART?

Anyone figured out how to do this? I’ve got a microUSB plugging into the EXT. board’s USB-UART (note: not the USB-UART for the keyboard) but cannot seem to pull up any output. Here’s what I’ve tried so far:

1500000bps N/8/1 (i.e. 1.5 Mbps, no parity, 8/1 bits, no flow control) - this is what uboot’s dtb for clockworkpi-a06 and /proc/cmdline indicate, as well as other rk3399 chips, but no dice

115200bps N/8/1 - this is what the kernel’s dtb for clockworkpi-a06 is set to for stdout (but is seemingly overridden at boot time with console=ttyS2,1500000)

Here’s what I see in dmesg/kmsg on my machine when trying to connect to the USB-UART (/dev/ttyUSB0):

$ sudo cat /proc/kmsg
<6>[866758.924517] usb 3-4: new full-speed USB device number 10 using xhci_hcd
<6>[866759.077542] usb 3-4: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
<6>[866759.077552] usb 3-4: Product: USB Serial
<6>[866759.080136] usb 3-4: ch341-uart converter now attached to ttyUSB0
<3>[866785.945056] usb 3-4: failed to send control message: -71

Bonus points if you know how to capture output from u-boot too, over UART.

Any of the Clockwork folks around to drop some UART debugging tips or others who have tried?

2 Likes

After disconnecting, waiting, reconnecting a few times, eventually I was able to get picocom to connect. I did a reboot, and voila, a little bit of u-boot output:

$ sudo picocom /dev/ttyUSB0 -b 1500000
picocom v3.1

port is        : /dev/ttyUSB0
flowcontrol    : none
baudrate is    : 1500000
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

!! Settings mismatch !! Type [C-a] [C-v] to see actual port settings
Type [C-a] [C-h] to see available commands
Terminal ready

*** baud: 1500000 (9600)
*** flow: none
*** parity: none
*** databits: 8
*** stopbits: 1
*** dtr: up
*** rts: up
*** mctl: DTR:1 DSR:0 DCD:0 RTS:1 CTS:0 RI:0
DDR Version 1.24 20191016
In
soft reset
SRX
channel 0
CS = 0
MR0=0x98
MR472
MR14=0x72
MR18=0x0
MR19=0xass!
channel 0, cs 0, advanced training done
channel 0, cs 1, advanced training done
channel 1, cs 0, advanced training done
channel 1, cs 1, advanced training done
change freq to 856MHz 1ddr_set_rate to 328MHZ
ddr_set_rate to 666MHZ
ddr_set_rate to 416MHZ, ctl_index 0
ddr_set_rate to 856MHZ, ctlBoot1: 2019-03-14, version: 1.19
CPU�d = 0x0
ChipType = 0x10, mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card dct!
emmc reinit
mmc: ERROR: SDmmc: ERROR: Card did not respondmmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
Us2000 , 0
StorageInit ok = 54891

U-Boot 2020.10-armbian (Aug 19 2021 - 06:54:26 +0000)

Mod3.9 GiB
PMIC:  RK808 
MMC:   mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from MMC... Card did not respond to voltage select!
*** Warning - No bloc� 28647936 bytes read in 1216 ms (22.5 MiB/s)
77505 bytes read in 12 ms (6.2 MiB/s)
2698 bytes read in 9 ms (292 KiB fi�up script (rockchip-fixup.scacy Image at 06000000 ...
   Im

does not carry through to kernel boot it seems, and there’s a bit of noise here, so I’m guessing doing some custom u-boot and kernel builds to use 115200bps will get some better output

5 Likes

Just seeing this thread now…I’ve been trying to get this working too with less success. So when you connect the debug microUSB port to your machine it registers as /dev/ttyUSB0? I haven’t been able to get that far, but that’s encouraging.

Have you understood if/how one would be able to use this UART for other things? I.e. which module is using that UART and if it can be disabled to be used by something else?

1 Like

Would suggest using as short of a micro USB cable as you can find. Fixed the baudrate issues I was running into.

The USB-UART is a ch341, and I believe its wired to the relevant UART pins on the CPU itself, so I suspect you cannot reuse this specific UART for anything else than as a console

Would suggest checking dmesg after you plug in to see if it registers or whether there are any errors (I’ve noticed sometimes there’s issues bringing up but plugging in again can fix it)

2 Likes

Tried all that again, but all I’m getting is a whole bunch of device not responding to setup address and unable to enumerate USB device, no matter how often I replug it.

The problem are the decoupling capacitor C11, they fitted a 1nF where you need at least 10nF.

It does not sounds a lot, but is enough the make the chip unstable and unable to boot properly.

It may work for some are analog is never all or nothing, some chip will work where other will not.

1 Like

I confirmed that communication is possible with DevTerm R-01 with the following settings.
Communication will fail if the USB cable is long.

https://github.com/emutyworks/DevTerm-R01/wiki/Connect-with-USB-UART
115200bps 8/N/1

Cablecc USB 2.0 (Type-A - Micro-B) Data Flat Slim FPC Cable

1 Like

FYI, all of this advice is valid for the CM4 model as well, but additionally you need to set enable_uart=1 in /boot/config.txt. More details on the Raspberry Pi specifics (including how to get bootloader logs): Attaching to a Raspberry Pi's Serial Console (UART) for debugging | Jeff Geerling

1 Like