# HG changeset patch # User Mychaela Falconia # Date 1626670875 0 # Node ID 2ac10b2cde4f8c9a221b8f06115c187ad154f756 # Parent bf7a0c2b2b50bac7109cc881da4c69f3d78b07f8 DUART28-PPD-surprise article written diff -r bf7a0c2b2b50 -r 2ac10b2cde4f DUART28-PPD-surprise --- /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.