Serial debugging:Cable schematics
Some phones have a serial port accessible from the outside, this makes debugging boot problems way easier since you can see the boot messages from the bootloader and the early kernel stuff. For example the whole nexus range has serial debugging through the headphone jack.
- 1 Nexus debug cable
- 2 USB debug cable
- 3 Mediatek USB debug cable
- 4 Mozilla Flame
- 5 Nokia N900
- 6 Motorola Droid 4
- 7 Sony Xperia
- 8 Suzy-Q debug cable
- 9 Android Debug Cable
- 10 Samsung Galaxy S7 and S5
- 11 Some Motorola Devices
- 12 Alternatives to a serial cable
- 13 Finding the serial port on your device
- 14 Soldering a connector on your device
- 15 3.3V vs 1.8V UARTs
- 16 See also
Nexus debug cable
The nexus phones multiplexed the serial debug lines with the headphone audio lines. To switch it into serial mode you have to supply -3V to the mic port. The UART lines themselves are 1.8V. If you use a 3.3V usb-to-uart adapter the signal from the phone will probably work, for the TX side you have to add a resistor divider to lower the voltage for the phone. Here's the schematic for a nexus debug cable:
This cable has been tested with:
- Google Nexus 5 (lg-hammerhead)
- Google Nexus 5X (lg-bullhead)
- Google Pixel (google-pixel)
- Google Nexus 9 (htc-flounder)
It should work fine with:
- Nexus 7 2013 (flo)
The Nexus 7 2012 (grouper) does not work with this setup and likely does not have any serial UART capabilities at all.
Google open sourced their own debug cable design in the AOSP repository.
NT: You will have a better luck with FTDI based serial cable.
USB debug cable
The Nexus S, Galaxy Nexus and other many other devices have the serial port multiplexed with the micro/mini USB connector, initially implemented as part of carkit standard. This is the schematic for those devices,
For this cable too it's important to have a 3.3V usb-to-uart adapter. It's not known whether the different ICs do level conversion, but if they don't, the voltage would be determined by the SoC's specs (e.g 1.8v for msm8916). For safety, don't transmit to the device with 3.3v UART. It seems you can receive just fine though (tested with raspberry pi zero). If you have a multimeter, it might be nice to make a list of 100% known device+voltage pairs. (I don't have one, so I have to play it safe)
It should work with:
- Nexus S
- Galaxy Nexus
- Samsung GT-I8190 (Galaxy S3 mini) (PMIC: AB8505)
- Samsung GT-I5800 (Galaxy 3) (PMIC: MAX8998)
- Samsung GT-P1000 (Galaxy Tab P1000)
- Samsung GT-S8500 (Wave)
- Samsung GT-S5570 (Tass) (IC: FSA9280A)
- Samsung GT-I8530 (Galaxy Beam)
- Samsung Galaxy S III mini (samsung-golden)
- Samsung Galaxy Xcover 2 (samsung-skomer)
- Samsung i897 (Captivate)
- Samsung Galaxy Tab S 10.5 WiFi (samsung-chagallwifi)
- Samsung GT-i9195 (Galaxy S4 mini) (IC: TSU6721)
- Samsung Galaxy S5 (samsung-klte)
- Samsung G530H (IC: SM5502)
- LG P700/P705 (IC: LP8727)
- LG P500 (IC: TS5USBA)
|Speed||Data bits||Stop bits||Parity||Flow control|
|Resistor (R3)||Connected VCC|
|Google Galaxy Nexus (GSM)||samsung-maguro||619K ohm||No|
|Samsung Galaxy Mini 2||samsung-s6500d||530K ohm||No|
|Samsung Galaxy S4 Mini LTE||samsung-i9195||619K ohm||No|
|Samsung Galaxy S5||samsung-klte||619K ohm||No|
|Samsung Galaxy Note 3||samsung-hlte||619K ohm||No|
|Samsung Galaxy S III mini (samsung-golden)||samsung-golden||619K ohm||No|
|Samsung Galaxy Xcover 2 (samsung-skomer)||samsung-golden||619K ohm||No|
|Samsung Galaxy Note 8.0||samsung-n5110||619K ohm||No|
|Samsung Galaxy Tab S||samsung-chagallwifi||619K ohm||No|
Mediatek USB debug cable
Some Mediatek devices expose an 3.3V uart interface at the usb port when a special Mediatek debug cable is attached to the device while booting
The schematic for this debug cable is the same as the Nexus USB debug cable above, except that the ID pin shouldn't be connected.
The Flame has open UART pads that are accessible underneath the outer and inner covers.
- TX - red
- GND - green
Pull-ups/downs are unneccesary, hook straight up to any FTDI/USB-to-serial.
See the following links:
Motorola Droid 4
A off-the-shelf USB-TTL Adapter with 3.3V signal level can be used together with a MicroUSB connector to access the phone's UART. By using a standard MicroUSB <-> USB A cable and just combine a USB jack with a cheap chinese USB-TTL adapter is space-saving and allows you to use the same MicroUSB cable to access the device in USB mode
See this page.
Suzy-Q debug cable
The Suzy-Q debug cable isn't strictly a serial debug cable, it accesses the Closed Case Debugging system, it can access multiple busses on the device. This system was originally developed to debug chromebooks but has been used in the newer Pixel phones. Details for the Closed Case Debugging system can be found at https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging.md
The official SuzyQable from Google has an 2 port USB hub into the cable itself, one port connects to the normal usb lines in the USB-C connector and the other port connects to the CC1/RFU1 pair like the diagram above, this way you can use both interfaces at the same time. The debug mode with the cable also only works on one of the two orientations in the USB-C socket. The official cable has a "DBG" mark on the C connector that should be facing up when plugged into the device. The other way around it will act as a normal USB cable.
That cable can be used with ChromeOS based devices for serial access.
Android Debug Cable
While reported online that a "Suzy-Q" cable can be used for Android-based Pixel devices, the cable available from Sparkfun, the SuzyQable, is not the right cable for debugging Pixel phones. They are using a different incompatible scheme[How?]. On Pixel 2 devices they will not work at all, and on Pixel 3, it is reported they show the console of the Titan M chip only.
Serial access for the Pixel 2 and 3 (unverified with 3a and 4) can instead be achieved using the following Android Debug Cable. Note that using a pass-through breakout board is not mandatory, but is helpful to keep the serial console active while using ADB.
This cable should work with:
- Google Pixel 2
- Google Pixel 3
Samsung Galaxy S7 and S5
See this guide. It worked almost exactly for the S5, only kernel MUIC driver was in another directory.
Some Motorola Devices
On here, find your device, and download and extract the file,then:
- open the one contains schematics.
- search keyword
*_DBG_UART_*) and see where it goes to(usually it's
- in some device(like
motorola-harpia),tx and rx will connect to a test pad(
TP_*),which makes it easier to access.
- in some device(like
- find it in board layout and on the device.
Alternatives to a serial cable
There might not be a need for a serial cable if you think it is too complicated to make one for your device (although it is much more convenient when it works). From there, about the Google Nexus 7 2013 (asus-flo):
If you cannot get it booting you will need to reboot into recovery and check /proc/last_kmsg for the errors. Or try and build the UART cable (which I failed at)
Also, a sony employee gave an alternative method here, that might be worth a go:
Unfortunately the only way to access the serial port is to open the device but.... You have the other option to debug - pstore: 1. flash an aosp recovery image with a working kernel to the recovery partition 2. to flash your new kernel on the main partition and boot After your new kernel crashes keep volume down pressed and you will boot the working kernel from the recovery partition. From recovery you have access to adb and you can extract the logs from pstore
Finding the serial port on your device
Sometimes there is no other solution but to poke at random motherboard pins to find the serial port. This is mostly a lucky process, but you can:
- send either garbage, or a repeating pattern to the serial port at
/dev/ttysomething(if you have a kernel where it's working), and then try to find the tx pin with a scope.
- If you can't, you can also reboot your phone and hope it writes something during boot (but that's really trying luck)
- tx is usually good enough for debugging, but rx should be quite close, with a high impedance, or more likely a pulling resistor.
- a pull-up or pull-down resistor will make the pin look like gnd or vcc
Soldering a connector on your device
This can be a bit involved, but is generally necessary if you want to use it:
- This procedure is dangerous for your device, even more so if you are not very experienced
- Prefer to ask help in a hackerspace, makerspace, fablab or similar you'll practice another day on something easier
- If you have to solder it yourself, it's probably a good idea to practice on an old motherboard before
- Prefer soldering short cables to the PCB instead of full-length ones
- The smaller (diameter) the cables, the better, generally
- too long or too thick and the pads you have soldered risk being teared apart by the cables
- too small and it will be a hassle to work with
- The best is to have them a couple (4-8) centimeters long, to solder them, solder a connector on the other end, and scotch tape them to the pcb
- Please, don't forget to pick insulated wires
3.3V vs 1.8V UARTs
Most phones expose their UART pins on 1.8V voltage, and most USB-UART converters expect UART side to have 3.3V. This works well for receiving characters from device; this is enough to read bootloader logs or kernel boot logs (dmesg). However sending 3.3V to device that expects 1.8V is dangerous; so you can't use shell over UART without an additional effort.
You'll need a voltage divider at least on converter->device TX line: use this answer https://electronics.stackexchange.com/a/333230