CP2105 UART advisory

[Mychaela Falconia]

Hello FreeCalypso community,

Seeing that our colleagues (in the generic GSM and cellular telecom
sense) over at Sysmocom have set up our FCDEV3B board with their
mv-uart adapter board for the USB-to-dual-UART function instead of the
more familiar to me FT2232x, I have done some reading-up on the
previously unfamiliar to me CP2105 chip they are using:

https://osmocom.org/projects/mv-uart/wiki

One issue that matters for Calypso and likely other GSM devices is
support for non-standard high baud rates.  GSM chipsets typically run
with a 13 MHz clock or some integral multiple thereof (our Calypso+RF
chipset features a 26 MHz clock in the RF section which is then
divided down to 13 MHz inside the Calypso), and this 13 MHz clock is
fed everywhere including the UARTs.  I also have every reason to
suspect that it isn't just TI, but other GSM chipset vendors have
probably done likewise, as everything in GSM land is based on clocks
that are integrally related to 13 MHz.

When a UART is fed with a 13 MHz clock, that UART can produce the
standard PC baud rate of 115200 bps (set the divisor to 7), but
instead of 230400, 460800 or 921600 baud it can only produce 203125,
406250 and 812500 baud, which are non-standard outside of the arcane
realm of GSM.  Thus if one wishes to talk to a Calypso device faster
than 115200 bps, non-standard GSM baud rates have to be invoked.

We have well-established ways of using these high GSM baud rates with
CP2102 and FTDI adapters: CP2102 has an on-chip EEPROM with a baud
rate remapping table which needs to be programmed; FTDI adapters don't
remap and thus don't need any EEPROM programming, but then userspace
programs need to request the actual required non-standard baud rates
from the kernel, which gets tricky and requires going outside of POSIX
- we got the needed magic in our tools starting with fc-host-tools-r7.
But I hadn't looked into the newer CP2105 chip until now.

Well, I did read up on it just now, and I am disappointed.  Like
FT2232x but unlike CP2102, this new CP2105 chip provides two UARTs
with one USB device.  However, unlike the two channels of FT2232x
which function identically in UART mode, the two UARTs of CP2105 are
not identical: one is what Silabs called the Enhanced Communication
Interface (ECI) and the other is what they call the Standard
Communication Interface (SCI).  Based on my reading of the chip
datasheet, it appears that the SCI UART cannot support any baud rates
outside of their fixed set at all (thus *no* ability to use high GSM
baud rates), whereas the ECI UART allows arbitrary baud rates
similarly to FTDI.  It appears that CP2105 does *not* have an on-chip
programmable baud rate remapping table like CP2102; it still has
on-chip non-volatile memory for other configuration bits, but it
appears to have been changed from EEPROM to OTP, meaning that you can
only program it once, and if you make a mistake, you blow the board.

One may think that there is no problem since one of CP2105's two UARTs
does support arbitrary baud rates in an FTDI-like manner: the most
common use case for high baud rates in FreeCalypso is flashing firmware
images with fc-loadtool, and this operation works exactly the same
through either UART, so there is no big problem with having only one
UART with high baud rate capability, right?  The limitation of having
high baud rate support on only one UART out of the two is certainly
livable (though certainly not ideal), but at the present time there is
another obstacle: the cp210x driver in all Linux kernel releases to
date forces all baud rate requests to the old CP2102 set, thus
requesting 203125, 406250 or 812500 bps on a CP2105 with any of the
released-so-far Linux kernel versions will NOT work.

This bug in the cp210x driver has just been fixed less than 2 months
ago, and the fix has made it into Linux mainline as of 4.19-rc1.
However, the last full release as of right now is still 4.18 which
still has broken support for arbitrary baud rates on CP2105 ECI, thus
it won't be until 4.19 full release before we'll see the fix in a
mainline Linux production kernel.  And then it will be another while
before kernels with the fix make their way into major distros - thus
anyone who needs to use a CP2105 adapter to talk to a Calypso device
at high baud rates right now or in the near future will have to patch
their kernel locally.

Conclusion: in light of the Linux kernel driver issue and in light of
the more fundamental limitation of the chip itself in terms of
supporting arbitrary baud rates on only one UART channel, I do NOT
recommend using CP2105 adapters like Sysmocom's mv-uart with our
FreeCalypso development boards, especially when working with our
FreeCalypso sw and fw which use both UARTs, unlike our competitor
OsmocomBB's use of only one UART.  Instead I recommend using more
classic FT2232x adapters (either FT2232C/D or FT2232H) in which both
UART channels function identically and which have been well-supported
by Linux for a long time.

It is true that FT2232x I/O pins don't go below 3.3 V, whereas CP2105
can go down to 1.8 V - hence Sysmocom folks were able to build their
mv-uart around CP2105 with no sweat, whereas doing a similar feat with
FT2232x would require additional on-board logic with voltage level
translating buffers, plus the external crystal and EEPROM needed with
FT2232x but not CP2102 or CP2105.  However, the UARTs on our dear
Calypso do not require such trickery: their native logic voltage is
2.8 V, but they are tolerant of 3.3 V inputs, and their 2.8 V outputs
do satisfy the Vih spec of FT2232x I/O pins operating at 3.3 V.  Thus
while connecting Calypso UARTs to an unbuffered FT2232x board running
at 3.3 V may not be as ideally-proper as connecting them to a native
2.8 V device like Sysmocom's mv-uart, the greater robustness of
FT2232x adapters outweighs this slight voltage level mismatch blemish
in my opinion.  These are the adapter boards I currently use and
endorse:

http://pldkit.com/other/ft2232d-module

The gentleman who makes these boards originally designed them with
FT2232D in mind, then he found some supply of the no-longer-made
FT2232C chips that are apparently cheaper than the price of new
FT2232D chips from Digi-Key, and it looks like he is now populating
these FT2232C chips on current board orders.  There is no difference
between these chip versions for UART, JTAG and other operating modes
besides CPU-style FIFO, and if someone really needs FT2232D, I'm sure
he'll be willing to populate an FT2232D chip for you if you ask him.

The above is an unbuffered FT2232C/D breakout board and works straight
out of the box if both channels are to be used as UARTs.  Another
common mode of usage is to configure Channel A as MPSSE for JTAG, but
I am not too comfortable with wiring up an unbuffered FT2232x board to
Calypso JTAG pins: one stupid misfeature of these FT2232x chips is
that bit modes like MPSSE cannot be configured in the EEPROM, and the
chip operates in the default UART mode until the user runs the
appropriate userspace program to put it into the right bit mode.  The
I/O pin that needs to be wired to TDO for JTAG (input to the adapter
in JTAG mode) operates as an output in the power-up default UART mode,
thus prior to userspace action, the two drivers on that line will
potentially fight - and I would rather not stress the hardware and
risk damage with such driver fighting.

As a low-priority background project, I am designing a FreeCalypso
UART+JTAG adapter based on the FT2232D chip.  It will differ from an
unbuffered FT2232x board like the one from PLDkit in that I will put
some buffer logic on the board between FT2232D I/O pins and the target
connection interface that will keep the target-interfacing JTAG lines
disconnected until the FT2232D channel is switched into MPSSE+GPIO
mode by userspace action.  And since I need buffer logic for that
purpose anyway, I will also make it put out proper 2.8 V on the target
interface side while at it.  But that board will be a UART+JTAG
adapter, putting out only one UART.  For the use case of getting two
UARTs from a single USB device, the best currently available option
IMO is to use an unbuffered FT2232x board from any of the "cottage
industry" vendors.

Hasta la Victoria, Siempre,
Mychaela aka The Mother