1. Introduction

FC Venus board will consist of two principal circuit domains: the mobile domain
corresponding to a battery-powered mobile phone and a USB computer interface
block which becomes the USB domain.  The USB domain will be based around FT2232D
USB to dual UART chip, it will be strictly bus-powered (never taking any power
from the battery), and its sole purpose is to provide a host computer interface
to the mobile, i.e., make the two Calypso UARTs accessible via USB.  The USB
domain will get powered only when a host computer (or a USB charger) is
connected, and will be totally unpowered at all other times, i.e., when the
board is untethered and runs on battery power like a true mobile phone.

At the top level of circuit hierarchy (see src/top/board.v), our board consists
of the two principal domains (mobile and USB) interconnected with just a few
wires: common ground, the set of UART signals going between the two domains, a
charging power supply rail (user-switched, so charging won't always happen when
a USB host is connected) and a couple of boot control signals.

2. UART signals between domains

The connection of UART interface signals between USB and mobile domains is
arguably the most challenging and the most complicated part of our entire
built-in USB-serial arrangement.  The challenges and the circuit complexity
which we came up with in response to these challenges stem from the need to
avoid bad things happening in partial power-down scenarios.  Most of the
background information is provided in section 1.12.2 of our FreeCalypso Handset
Specification (FC-handset-spec in freecalypso-docs), and this document provides
further details that were elucidated only in the process of capturing the actual
circuit design for FC Venus.

2.1. Set of signals

The set of UART interface signals implemented on FC Venus will be the same as
listed in FC Handset Specification section 1.12.1.  We have a total of 5 signals
running from Calypso outputs to FT2232D, and a total of 4 signals running from
FT2232D to Calypso inputs.

2.2. Buffer ICs

Two Nexperia LVC family buffer ICs will be used on FC Venus for the purpose of
ferrying our set of UART interface signals between the two domains.  These two
ICs are U401 (74LVC125A) in the mobile domain and U705 (74LVC541A) in the USB
domain.

U401 is powered from the mobile domain's Vio rail, and it serves only the 4
signals running from FT2232D to Calypso inputs, neatly using all 4 slots of
74LVC125A.  This LVC buffer serves as a barrier, preventing feeding of power
from USB domain outputs into the Calypso+Iota chipset's Vio rail in the PPD
scenario where a USB host is connected, but the charging switch is off or the
battery is critically low and undergoing precharge, with the chipset switched
off.

No corresponding mobile domain buffers will be used for Calypso outputs: these
5 signals will be connected directly between Calypso pads and the interdomain
interface, where they will go to U705.

On the USB side, U705 will be powered from a USB domain 3.3V rail, i.e., the
output of a 3.3V regulator powered from USB.  (This USB domain supply will be
the only part of FC Venus board using 3.3V - there are no regulated voltages
higher than 2.8V in the mobile domain.)  The 8 slots of this 74LVC541A buffer
are split between 5 serving the Calypso to FT2232D signal direction and the
other 3 serving FT2232D to Calypso signals.

The purpose of the 5 U705 buffer slots serving the Calypso to FT2232D signal
direction is to stop the flow of current out of Calypso UART and GPIO outputs
in the "normal mobile usage" PPD scenario when there is no USB host connected.
With this buffer present, Calypso UART outputs will "see" a high impedance and
won't source any battery-drawn current (beyond leakage of about 0.1 uA typical
per pin, according to Nexperia datasheet), no matter whether the USB domain is
powered or not.  OTOH, if this buffer were omitted and Calypso outputs were
connected directly to FT2232D inputs, the latter inputs would appear as shorts
to ground when USB power is absent, putting an unacceptable load on Calypso
outputs.

The other 3 slots of U705 serve FT2232D-to-Calypso signals TxD, DTR and TxD2.
On these 3 signals there are pull-up resistors to VBAT in front of U401 inputs
(see section 2.4), and the U705 buffer's Ioff feature will allow those pull-up
resistors to work as intended.  If these pulled-up-to-VBAT nets going to U401
inputs were sourced directly from FT2232D outputs without going through U705,
the powered-off FT2232D chip's I/O pins would present a lower resistance to GND
than the pull-up to VBAT, drawing excessive current from the battery and making
the pull-up ineffective.

There is just one FT2232D-to-Calypso UART interface signal that does not go
through U705, and it is RTS.  It has a pull-down resistor to GND instead of a
pull-up to VBAT in front of its U401 input.  With only 8 signals rather than
all 9 needing to go through a USB domain LVC buffer, the 8 slots of a single
74LVC541A IC become sufficient.

2.3. UART signals from Calypso to FT2232D

In the case of these 5 signals running from Calypso outputs to U705 inputs, one
very noteworthy detail is that there are _no_ pull-up or pull-down resistors on
these nets.  When the Calypso+Iota chipset is switched on, all 5 Calypso outputs
will be actively driving and there are no problem issues.  However, in the PPD
scenario where a USB host is connected, but the Calypso+Iota chipset is switched
off (the charging switch is off or the battery is precharging), the absence of
pull resistors suggests that U705 inputs will be floating, which certainly looks
bad at first glance.

However, a more detailed analysis shows that floating CMOS inputs aren't bad
"in principle", but instead they are bad when they can float around the input
switching threshold, causing potential oscillations and high current draw from
the buffer's Vcc supply.  And in the present case, the Mother's analysis
suggests that the signals in question won't float around the switching threshold
- instead we expect them to be sensed as a consistent logic low in the PPD
scenario in which they appear to float.

In this PPD scenario, the Iota chip's VRIO regulator is off, thus the Vio rail
will be at 0 V unless something feeds wayward power into it.  Calypso chip
outputs connected to the signal nets under consideration have clamping diodes
to this Vio rail.  Therefore, if a stray voltage somehow accumulates on those
nets that is high enough to approach the LVC buffer's input switching threshold,
it will also be high enough to drain to Vio through Calypso I/O pad clamping
diodes, and ultimately to GND.

What is our reason for not adding pull-up or pull-down resistors to these nets?
Besides the obvious reason of not wanting to throw even more PCB real estate at
this already way overcomplicated USB-serial interface arrangement, each of the
two options (pull-up or pull-down) would introduce its own problems.

The pull-up resistor option has already proven to be problematic on the
DUART28+Caramel2 combo, particularly in the Luna configuration in which both PPD
scenarios become real.  When the Calypso+Iota chipset is on but there is no USB
power present, current from Calypso outputs flows backwards through these
pull-up resistors and feeds into the USB domain's power rail to which these
resistors are connected.  The USB domain output buffer then powers up
erratically, feeding garbage to Calypso inputs and preventing Calypso from
entering sleep modes.  And in the opposite PPD scenario (USB power present,
chipset switched off), enough power can flow through these resistors into
Calypso I/O pad clamping diodes to feed into Vio and cause erratic LED
behaviour!  And on FC Venus we would have the additional problem of not having
a USB-powered 2.8V regulator, as we don't need it for anything else.

Pull-down resistors to GND would be much less problematic.  However, if we use
a resistor value that is low enough to be better than floating, such as the
"canonical" 100 kOhm, we would be introducing a *continuous* drain on the
battery in normal operation.  Calypso outputs corresponding to host RxD, RxD2,
DCD and RI will normally be high, thus each of those would be a 28 uA drain.
All 4 combine into a 112 uA continuous drain for no good justification, always
present whether or not there is a USB host connected, unlike the other similar
drain discussed in section 2.4.  Therefore, the Mother's decision is to do away
with pull resistors in either direction, and hope that my reasoning is correct
in that we won't get prolonged floating voltages around the input switching
threshold.

Because these seemingly-floating nets are expected to be sensed as logic low,
the same logic low will be propagated to FT2232D inputs, which means a break
condition on RxD and asserted state on all control signals.  For this reason
the Mother's earlier software recommendation still holds: when operating in this
scenario, only operate on the second UART channel (the data leads only one that
also has boot controls), and don't open the AT command UART channel except when
the mobile is switched on and regular operational firmware runs normally.

2.4. Pull-up resistors to VBAT

Experience with Caramel2 boards shows that Calypso UARTs don't like seeing a
break condition presented to them for extended lengths of time, thus we need to
design our FC Venus USB-serial interface in such a way that when there is no USB
host present, Calypso inputs RX_MODEM and RX_IRDA will receive high levels
(meaning RS-232 idle) rather than low (meaning RS-232 break).  Having an
extended break condition presented to UARTs prevents entry into Calypso sleep
modes, which is obviously bad.  The practical implication is that U401 inputs
which this buffer propagates to Calypso RX_MODEM and RX_IRDA need to be have
some kind of mobile domain pull-ups on them, as opposed to floating or pulled
down.  Less critically, we do the same for the DTR signal running from the USB
domain to the mobile domain - thus DTR will be seen as negated when there is no
USB host connected.

However, if we were to implement pull-ups to the Calypso+Iota chipset's Vio rail
on these nets, we would have a problem in the PPD scenario of USB power present,
chipset switched off: U705 high outputs would feed power into Vio through these
resistors, potentially causing Calypso peripherals to turn on erratically as
has been observed on Caramel2 boards.  Therefore, we are making a more unusual
innovation: instead of pull-ups to Vio, we are implementing pull-ups to VBAT,
i.e., to the unregulated raw positive battery terminal.  The resistor value
chosen by the Mother is 22 kOhm, and the rest of this section explores the
implications of this unusual design under all expected conditions.

First let us examine what happens in the case of "normal" mobile usage: the
device is untethered and mobile, powered by the battery, and there is no USB
host or charger connected.  In this case the input voltage seen by U401 will be
raw VBAT, which will always be higher than its 2.8V supply (but still safely
below the 5.5 V limit), thus the LVC buffer will sense a good logic high as
desired.  The current drawn from the battery through these pull resistors will
be the sum of U705 Ioff and U401 Ii, each of which is listed as 0.1 uA typical
in Nexperia datasheets.  The listed worst case specs are 10 uA for Ioff and 5 uA
for Ii, thus under presumably very rare conditions, we could have a maximum
current draw of 15 uA per each of the 3 pull-ups.  15 uA times 22 kOhm equals a
voltage drop of 330 mV, thus U401 inputs will remain at 2.8 V or above (meaning
no increased Vio supply current draw) with the battery as low as 3.1 V, which
is below the operational range for the mobile.

Now consider what happens when USB power is plugged in, either a host computer
or a charger.  FT2232D will power up in UART mode and start putting out logic
high on all of its outputs (the state when no one opens either of the two serial
ports in host computer software); U705 will also power up and start putting out
the same logic high on the 3 signal nets going to the mobile domain.  At this
point U705 output pads are no longer in their Ioff state, instead they are in
the actively driving high state, and Nexperia datasheet says that the voltage
at these output pins should not exceed Vcc, which is 3.3 V in the present case.
VBAT can be as high as 4.2 V, thus we are operating the 74LVC541A under somewhat
adverse conditions.

The undesirable adverse condition is that current will flow through the LVC
buffer's output p-channel MOSFET (open for driving high) in the wrong direction.
The maximum magnitude of this current is about 41 uA, computed as
(4.2-3.3 V) / 22 kOhm.  This current magnitude is expected to be far too low to
damage the 74LVC541A IC (the limiting values Iok spec is 50 mA), thus the only
remaining concern would be feeding of a higher voltage into the USB domain's
regulated 3.3V rail.  This concern is addressed in the following subsection.

Aside from the issues of reverse current flow through the LVC buffer's output
p-channel MOSFET, the other concern with this 41 uA current (at maximum VBAT)
is that this current is drained from the battery.  With a total of 3 such
pull-ups, we expect a total battery drain current of 123 uA at maximum battery
charge - but this current only turns on when USB power is applied, and the
current into U705 output pins goes up from 0.1 uA to 41 uA per pin.  However,
when USB power is applied for extended periods of time, it is usually done for
the purpose of charging the battery, and the charging current of 500 mA far
exceeds the drain current of 123 uA.  In order for the battery to not be
charging when USB power is present, the system would have to be in one of two
other states: either the user connected USB for computer interface purposes and
not for charging (the charging switch is off), or the charge cycle finished but
the user hasn't unplugged the charger yet.  Both of these conditions are not
expected to persist for unreasonably long time spans, hence the Mother deems it
acceptable to impose this 123 uA battery drain during times of active computer
interfacing.

In the case when the charging switch is on and the charging cycle has finished,
it is also important to consider that Iota ABB sleep is prevented for as long as
VCHG remains applied to the chipset, which holds whenever USB power is present
and the charging switch is on.  In this state (charging cycle finished, but VCHG
not removed yet) Calypso can enter deep sleep (the main VCXO is stopped), but
Iota ABB sleep is prevented.  According to TI's APN2_110.pdf document, the
difference in battery power draw between deep and "superdeep" sleep modes is
about 600 uA - thus leaving the charger plugged in after charge cycle completion
causes even more battery drain through this other mechanism than through our
VBAT pull-up resistors in the USB-serial interface.

Finally, whenever any of the 3 USB domain outputs in question (TxD, DTR or TxD2)
drives low, the current drawn from VBAT on that net increases from 41 uA to
about 190 uA at maximum VBAT, computed as 4.2 V / 22 kOhm.  However, this
condition only occurs when the operator does active host computer interfacing
with software (the main AT command UART needs to be opened in order for DTR to
go low, and each of the two TxD lines goes low only when the host computer
actively transmits bytes), thus this increased battery current draw corresponds
to explicit user activity, rather than something that happens on its own.  In
contrast, typical user activity on an untethered phone involves the LCD and its
backlight turning on, consuming tens of mA instead of hundreds of uA.

It also needs to be noted that all of these currents are drawn directly from the
battery without going through Iota LDO regulators, thus none of these uA numbers
come out of the 1 mA sleep mode Vio current budget.

2.4.1. USB domain 3.3V load resistor

One concern raised in the analysis of VBAT pull-ups is that when current flows
from the battery into the USB domain's P_3V3 rail through U705 outputs in
reverse, the effect may be to raise that rail above 3.3 V.  To prevent this
effect, the Mother's idea is to add a load resistor to the USB domain, a
3.3 kOhm load permanently placed between P_3V3 and GND, producing a permanent
1 mA draw from USB, going through our 3.3V regulator.  For comparison, FT2232D
is said to draw about 30 mA of supply current, although the datasheet does not
specify how it breaks down between Vcc and Vccio supply currents, hence most of
this 30 mA is probably drawn directly from USB 5V, without going through our
3.3V regulator.  The addition of 1 mA to the overall USB current draw can be
considered insignificant (especially for 500 mA charging, but even for 30 mA
host computer interfacing), but with a guaranteed load of at least 1 mA on
P_3V3, any wayward current coming from the battery (123 uA maximum) will always
be absorbed into this load without raising P_3V3 above its intended 3.3 V.

2.5. Pull-down to GND on Host_RTS

The effect of Host_RTS being sensed as low instead of high when there is no USB
host connected is that any unsolicited output on the AT command channel will be
flushed in this no-host-connected state, instead of being buffered in the
mobile.  Given that an end user mobile phone (as opposed to a dedicated cellular
modem) is expected to be untethered most of the time, having buffered output
accumulate while waiting for a host computer to be connected "some day" does not
sound like a good idea, hence having it flushed by unblocked flow control state
soundly appears to be the better option.  And with only 3 out of the 4 FT2232D
to Calypso signals needing pull-ups to VBAT, only 3 need U705 buffer slots,
making a single 74LVC541A buffer IC sufficient for both directions in the USB
domain.

The value of the pull-down resistor on the Host_RTS net (running from FT2232D
ADBUS2 output to U401 input) will be 47 kOhm.  When USB power is applied but no
one opens the AT command UART channel, FT2232D will drive its RTS output high,
sourcing about 70 uA of current from its USB 3.3V supply into the pull-down
resistor - well within FT2232D output current sourcing budget.

2.6. UART rescue header

With the built-in FT2232D subsystem becoming a part of the critical path for
board bring-up and any kind of Calypso GSM functionality, we get a new concern,
now that we live in an era of severe part shortages and insanely long lead
times: what if we are unable to get some critical part for this USB subsystem,
or run out of parts in the course of troubleshooting iterations?  Likewise,
what if some design mistake causes our USB subsystem to not work as intended,
thereby making the main Calypso GSM part of the board inaccessible?

The Mother's answer to this concern consists of a 10-pin header at reference
designator J301.  Out of the total of 9 UART signals running between mobile and
USB domains, 8 of these signals (all except Host_RI) plus two GND pins will be
wired to this header, in the same FreeCalypso dual UART pinout as used on
FCDEV3B and Caramel2.  If the USB subsystem is fully populated on a given Venus
board and if it works as designed, the only things that can be connected to J301
are oscilloscope probes - don't connect an external DUART28 or other adapter,
or you will cause a driver conflict between built-in USB outputs and that
external adapter.  However, if the entire USB subsystem is omitted from board
population (presumably due to part shortage), or if U705 and R707 are removed
following a discovery of killer problems in this subsystem, then an external
DUART28 adapter can be connected to J301, and it will effectively take the place
of the built-in USB subsystem that has been taken out.

2.6.1. DUART28 modifications

If we end up having to use an external DUART28 adapter board instead of the
built-in USB subsystem, that DUART28 will need to be slightly modified, as in
surgical rework:

* Adapter input pull-up resistors R11, R12, R14 and R16 will need to be removed
  - see section 2.3 above for the reasoning.

* A loading resistor will need to be added across C12 (perhaps soldered directly
  on top of the cap), following section 2.4.1 above.

Also because DUART28 adapter outputs are at 2.8V rather than 3.3V (DUART28 was
designed to feed signals directly to Calypso inputs, without a subsequent LVC
buffer in the Calypso domain), the current flowing from the mobile domain
battery into DUART28 P_2V8 through the 74LVC541A buffer's output p-channel
MOSFET in reverse increases from about 41 uA to about 58 uA per pin, accounting
for 2.2 kOhm series resistors on DUART28 outputs in addition to our 22 kOhm
pull-ups to VBAT.  We can either live with this slightly higher current, or we
can increase R401, R402 and R403 on those Venus boards that will go without
built-in USB.

3. Boot control signals

The two boot control signals RPWON and nTESTRESET properly belong in the mobile
domain.  They are pulled up to VBAT inside the mobile domain (RPWON is pulled up
to VBAT inside the Iota chip, nTESTRESET is pulled up to UPR with R208 per
Leonardo schematics), many other designs don't provide any way at all for these
signals to be pulled down, but on FC Venus we have a dual OD buffer (74LVC2G07)
in the USB domain that can pull either signal down on host command.  This dual
OD buffer is little different from a pair of dry contact pushbutton switches
shorting to GND, thus the two boot control signals don't bring on any of the
difficulties like those associated with the UART interface.