DUART28 partial power-down surprise behaviour
=============================================

FreeCalypso DUART28 adapter was specifically designed to handle partial
power-down scenarios as gracefully as possible.  There are two possible PPD
scenarios:

1) USB host is connected (USB power present), but the connected Calypso device
is in the switched-off state in the Iota VRPC sense.  This condition occurs all
the time in standard FreeCalypso workflows.

2) The connected Calypso device is up and running, but there is no USB host
connected.  This scenario is practically relevant only when the Calypso device
is equipped with LCD and keypad peripherals and runs handset firmware that is
capable of untethered operation.

As we have learned through experience with Caramel2 boards, PPD scenario 1
would be best handled on the Calypso device side by inserting an LVC buffer
powered from Calypso V-IO into Calypso input signal paths, rather than on the
USB adapter side.  However, for already existing Calypso boards which don't have
any such LVC buffers, DUART28 provides some improvement over the alternatives:
current feeding into powered-down Calypso inputs is reduced to 1.27 mA per pin,
and the outputs from the adapter are 2.8V rather than 3.3V.

For PPD scenario 2 (which matters for Caramel2 in the Luna configuration) we
were hoping that the combination of LVC input and output buffers on the DUART28
side and UART data line pull-up resistors on the Caramel2 side would do the
trick, and produce the graceful behaviour we were after.  Unfortunately though,
this PPD scenario does not work as well in practice as we hoped for at design
time.

DUART28 design includes pull-up resistors to the adapter's 2.8V rail in front of
all 6 LVC input buffers.  These pull-up resistors are there to keep these LVC
inputs from floating (and thus propagating garbage, possibly even rapidly
oscillating garbage, to FT2232D inputs) in the following scenarios:

1) PPD scenario 1;

2) Even more importantly, partial connection scenarios.  DSR input is currently
expected to be almost always unconnected, as none of our Calypso devices except
GTM900 feature DSR outputs; RI input is likewise connected only very rarely
(only available on Caramel2 and requires a separate wire connection), and there
is no DCD output on FCDEV3B, causing DCD input to be unconnected as well when
working with FCDEV3B.

However, these pull-up resistors create a nasty surprise in PPD scenario 2:
current from Calypso outputs flows in the reverse direction through these
pull-up resistors into the powered-down DUART28 adapter's P_2V8 rail, enough
power flows into that rail to power up the other LVC buffer serving adapter
outputs, those outputs drive low because the inputs coming from FT2232D are
powered-down low, and the inputs to Calypso UARTs become low instead of high.
Calypso UARTs apparently don't like it when their RxD inputs are continuously
low (break condition), and all Calypso sleep modes are disabled as the result.
The lack of sleep becomes visible on Caramel2 with the yellow STATUS LED
remaining lit continuously, rather than flashing with sleep-wake activity as it
does in expected normal operation.

What is incredible about this erratic behaviour scenario is how little power it
takes to turn on the LVC buffer serving adapter outputs.  With 3 out of 4
Calypso outputs driving high, the maximum total current that can flow through
the 3 100 kOhm resistors that stand in the way is 84 uA.  The voltage measured
at the P_2V8 circuit node in this condition is about 1.22 V, i.e., out of the
2.8 V put out by Calypso, about 1.6 V drops across the 100 kOhm resistors (thus
it seems that only about 16 uA flows through each resistor), and the unlucky
74LVC541A buffer IC gets powered up with just 48 uA at 1.22 V.  In this erratic
condition, the outputs of this buffer IC drive low strongly enough to overpower
the 100 kOhm pull-ups on Calypso inputs, and those latter inputs sense low
instead of high.

Measuring voltages at other circuit nodes in this state, we see that P_5V rests
at about 0.89 V - we are seeing reverse leakage through the 2.8V LDO regulator,
from its output to its input.  However, P_3V3 (the output of the other LDO
regulator) rises to no more than 8 mV - thankfully, not enough power comes in
through these back paths to turn on another separate LDO, and no spurious resets
are triggered via the 74LVC2G07 boot control circuit.

Possible solutions
==================

There are two general approaches we can take:

1) We can create DUART28 V2 with a more complex design for these pull-ups:
perhaps we can insert diodes somewhere to block the reverse current flow through
pull-up resistors, or seeing that P_3V3 is not powered on by this erratic back
feeding, we could add a third separate LDO regulator just for these pull-ups.

2) We can just live with this defect, as it is not particularly serious.

It is worth noting that the erratic behaviour in question occurs ONLY in PPD
scenario 2, and this PPD scenario is relevant ONLY for Caramel2+Luna setups:
not for FCDEV3B, and not for Caramel2 used in a modem configuration.  Given how
few FC community members are expected to work with Luna, and given that we have
a large surplus of unsold DUART28 boards, a simple solution would be to issue
two DUART28 boards to every community member who works with Luna, keep one board
unmodified (all 6 input pull-up resistors intact per the original design), and
modify the other board for Caramel2+Luna configuration.

If a DUART28 adapter board is to be modified specifically for C2+Luna, the
modification will consist of removing 4 0402 discrete resistors: R11, R12, R14
and R16.  These are pull-up resistors on RxD, CTS, DCD and RxD2 inputs - these
4 signals are the ones driven from Caramel2+Luna to DUART28.  OTOH, the other
two pull-up resistors for DSR and RI need to remain: there is no DSR output on
Caramel2, and Calypso GPIO1 (which could otherwise be RI) is made inaccessible
by Luna cabling.

A DUART28 adapter board that has been modified in this manner should be used
only with Caramel2 and not with FCDEV3B.  (Connecting FCDEV3B would result in a
floating LVC buffer input propagating garbage to FT2232D DCD input, which is
bad.)  Furthermore, even with Caramel2 (with or without Luna) certain user
behaviours will need to be adjusted when using a sans-pull-up DUART28 adapter:
specifically, all operations with fc-loadtool (flashing), fc-iram (miscellaneous
run-from-RAM programs) and fc-xram (FFS editor) need to be performed through the
secondary UART (the one that carries RVTMUX with running firmware), rather than
the primary UART that carries the main AT command channel.  In contrast, the
ttyUSB device corresponding to the primary UART should only be opened when the
Calypso+Iota chipset is switched on and the firmware is running.  The reason
for these user guidelines is that when a modified-DUART28 ttyUSB port is opened
while the Calypso+Iota chipset is switched off, FT2232D inputs will be receiving
garbage.  The primary UART channel has flow control and modem control signals,
whereas the secondary UART is data leads only - thus the Linux host will see
less bogosity on the latter.