# HG changeset patch # User Mychaela Falconia # Date 1623398684 0 # Node ID 7933c3a1b5e05d362a7e342f85eb4522c1c870fd # Parent da1a2a32c26085ba90c5a3decb2b97b1e6fc9426 FC-handset-spec: power domain mess documented diff -r da1a2a32c260 -r 7933c3a1b5e0 FC-handset-spec --- 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.