--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/DUART28-PPD-surprise	Mon Jul 19 05:01:15 2021 +0000
@@ -0,0 +1,121 @@
+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.