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