--- a/FC-handset-spec	Fri Jun 11 05:52:58 2021 +0000
+++ b/FC-handset-spec	Fri Jun 11 08:04:44 2021 +0000
@@ -776,13 +776,143 @@
 functional equivalent that fits inside the Neo, in some otherwise unused space.
 
 Hence the new design for our planned FC Libre Dumbphone handset: the USB port
-will have a built-in FT2232D subsystem (USB to two UARTs) connected to it,
-interfacing to both Calypso UARTs, while the charging on/off switch will make it
-possible to use this interface for low-level development and bring-up without
-presenting VCHG to the chipset.  In this architecture this FT2232D subsystem
-should be considered the primary "owner" of the handset's USB port, while the
-charging function is secondary and optional, enabled or disabled with a switch.
-To put it another way, if our USB port is connected to a regular USB host (as
-opposed to a Dedicated Charging Port power-only source), that USB host will
-always enumerate the FT2232D and see two ttyUSB devices, whereas charging may
-or may not take place depending on the switch setting.
+will have a built-in FT2232D (or perhaps FT2232H) subsystem (USB to two UARTs)
+connected to it, interfacing to both Calypso UARTs, while the charging on/off
+switch will make it possible to use this interface for low-level development
+and bring-up without presenting VCHG to the chipset.  In this architecture this
+FT2232x subsystem should be considered the primary "owner" of the handset's USB
+port, while the charging function is secondary and optional, enabled or disabled
+with a switch.  To put it another way, if our USB port is connected to a regular
+USB host (as opposed to a Dedicated Charging Port power-only source), that USB
+host will always enumerate the FT2232x and see two ttyUSB devices, whereas
+charging may or may not take place depending on the switch setting.
+
+1.12.1. Set of UART signals
+
+The set of signals to be connected between Calypso and FT2232x for the Modem
+UART is almost complete:
+
+USB UART
+DTE signal	Calypso signal
+------------------------------
+TxD		RX_MODEM
+RxD		TX_MODEM
+RTS		CTS_MODEM
+CTS		RTS_MODEM
+DTR		GPIO3
+DCD		GPIO2
+RI		GPIO8
+
+Only DSR is omitted for the Modem UART channel, all others are included.  The
+second debug UART channel is only two wires:
+
+USB UART
+DTE signal	Calypso signal
+------------------------------
+TxD		RX_IRDA
+RxD		TX_IRDA
+
+However, as shown in the next section, these signals cannot be simply connected
+between Calypso and FT2232x, and a more complicated scheme needs to be
+implemented instead.
+
+1.12.2. USB and mobile power domains
+
+Our FC Libre Dumbphone handset will have two principal power domains in it: the
+main battery-powered mobile domain, and the USB domain.  This power domain
+situation presents some very significant challenges, a problem generally
+referred to as "partial power-down".  There are two PPD scenarios to be
+concerned about:
+
+1) In normal operation the phone is mobile and not connected to USB.  In this
+   state the mobile power domain is on, whereas USB-powered circuits in the
+   FT2232x subsystem have no power.  The two challenges in this state are:
+
+1a) We need to ensure that no currents flow from the powered-on mobile domain
+    into powered-down USB domain circuits, as any such currents would be an
+    unacceptable drain on the battery.
+
+1b) Calypso UART inputs that come from the USB domain when the latter is active
+    need to have defined logic levels on them when the USB domain has no power:
+    no floating, no mid-way levels that would cause higher currents in CMOS
+    input structures, and furthermore, some Calypso inputs need to be high in
+    this state, while others need to be low.
+
+2) A reverse PPD scenario occurs when the USB domain has power, but the
+   Calypso+Iota chipset is in its switched-off state per Iota VRPC.  This
+   scenario can occur when the charging switch is set to off, or when the
+   battery is critically low and undergoing precharge.  The main concern in
+   this state is to avoid feeding power from the USB domain into the Calypso
+   chipset's V-IO rail - our experience on Caramel2 boards conclusively
+   demonstrates that Calypso does not like this condition and can behave oddly,
+   erratically feeding current into its outputs that are supposed to be low or
+   Hi-Z, and thereby erratically turning on various peripherals.
+
+If we were to naively connect our UART signals between Calypso and FT2232x, the
+result would be bad: all of the above concerns would be violated.  Instead we
+need to insert carefully designed isolating buffer circuits in both directions.
+
+1.12.2.1. Calypso to FT2232x signal direction
+
+If these signals were connected directly, significant current (in the mA range)
+would flow from Calypso outputs into powered-down FT2232x inputs, which is not
+acceptable.  Our solution is to insert an LVC buffer (probably 74LVC541A, for
+the 5 signals that are needed) between Calypso outputs and FT2232x inputs, with
+the buffer powered from USB domain 3.3V supply.  With mobile on and USB power
+absent, the LVC buffer's Ioff spec will apply, which is listed in Nexperia's
+74LVC541A datasheet as 0.1 uA typical, 10 uA maximum.
+
+An unfortunate consequence of this design is that in the opposite PPD scenario
+(USB connected to a host, charging switch off, mobile chipset in its off state)
+the inputs to the LVC buffer will float, with FT2232x inputs receiving garbage
+as a result.  Adding pull-up resistors to a USB-domain supply would cause other
+problems, hence the Mother's position is that we'll just live with a few
+floating inputs in this particular condition - and it is a condition that
+should not persist for extended lengths of time.  There is also a software
+consideration stemming from this floating input situation: when you are doing
+low-level programming and development operations in this state, don't open the
+Modem UART ttyUSB device, and only operate via the other debug UART.  The latter
+is a 2-wire UART without any flow control or modem control signals, hence there
+will be less bogosity for the Linux host to see in this state.
+
+1.12.2.2. FT2232x to Calypso signal direction
+
+This direction is even more difficult, and we will need to insert two chained
+LVC buffers: the signals will first pass through an LVC buffer powered from the
+USB domain, and then through another LVC buffer powered from the Calypso+Iota
+chipset's V-IO rail.  There will be pull resistors inserted between the two
+buffers: either pull-up to VBAT (raw battery positive rail) or pull-down to GND,
+depending on the needed signal sense.
+
+The LVC buffer powered from Calypso V-IO is needed in order to prevent current
+feeding into Calypso when the mobile is switched off - the buffer's Ioff spec
+will apply.  Pull-up and pull-down resistors in front of this buffer are needed
+so that Calypso inputs will receive the desired states when no USB host is
+connected.  Pull-ups are being made to VBAT instead of V-IO to eliminate the
+possibility of current feeding into V-IO through these resistors.  (Feeding
+from 3.3V logic signals into the battery can't happen when the battery is above
+3.3 V, and if the battery is below 3.3 V, then we are only adding a little to
+the precharge current.)
+
+The other LVC buffer (the one powered from USB-domain 3.3V) is needed because
+in the absence of this buffer, current will flow through pull-up resistors and
+into powered-down FT2232x output pins, the resulting pull-down resistance will
+be lower than the pull-up, and the next buffer won't receive the desired logic
+level, not to mention unwanted current flowing.  With the other LVC buffer
+added, that buffer's Ioff spec will apply.
+
+The value of pull-up resistors to VBAT will be 22 kOhm.  With maximum 15 uA
+current flowing through each resistor (worst-case Ioff of one buffer plus
+worst-case Ii of the other buffer), the maximum voltage drop on the 22 kOhm
+resistor will be 330 mV.  In order for the LVC buffer's input structure to not
+draw extra current, the input voltage needs to be 2.8 V or higher - thus with
+22 kOhm resistors we'll keep satisfying this condition until the battery falls
+to about 3.1 V, which is below the operational range for switched-on mobile.
+
+One downside of having pull-ups to VBAT (which can be as high as 4.2 V) on
+signals that are output from a 3.3V-powered buffer is that when the buffer
+output is high, there may be current flowing into that high output (not sourcing
+out of it as normally expected), which is a bad condition for CMOS outputs.
+However, this current will be limited to a maximum of about 40 uA
+((4.2-3.3 V) / 22 kOhm), and my feeling is that such small current won't hurt
+Nexperia LVC buffers.