FreeCalypso > hg > freecalypso-schem2

comparison venus/doc/USB-and-mobile-domains @ 38:32b848a081a3

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
venus/doc/USB-and-mobile-domains treatise written
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 26 Nov 2021 23:02:19 +0000
parents
children beb6519a3be5
comparison
equal deleted inserted replaced
37:9c2f913fa5cf 38:32b848a081a3
1 1. Introduction
2
3 FC Venus board will consist of two principal circuit domains: the mobile domain
4 corresponding to a battery-powered mobile phone and a USB computer interface
5 block which becomes the USB domain. The USB domain will be based around FT2232D
6 USB to dual UART chip, it will be strictly bus-powered (never taking any power
7 from the battery), and its sole purpose is to provide a host computer interface
8 to the mobile, i.e., make the two Calypso UARTs accessible via USB. The USB
9 domain will get powered only when a host computer (or a USB charger) is
10 connected, and will be totally unpowered at all other times, i.e., when the
11 board is untethered and runs on battery power like a true mobile phone.
12
13 At the top level of circuit hierarchy (see src/top/board.v), our board consists
14 of the two principal domains (mobile and USB) interconnected with just a few
15 wires: common ground, the set of UART signals going between the two domains, a
16 charging power supply rail (user-switched, so charging won't always happen when
17 a USB host is connected) and a couple of boot control signals.
18
19 2. UART signals between domains
20
21 The connection of UART interface signals between USB and mobile domains is
22 arguably the most challenging and the most complicated part of our entire
23 built-in USB-serial arrangement. The challenges and the circuit complexity
24 which we came up with in response to these challenges stem from the need to
25 avoid bad things happening in partial power-down scenarios. Most of the
26 background information is provided in section 1.12.2 of our FreeCalypso Handset
27 Specification (FC-handset-spec in freecalypso-docs), and this document provides
28 further details that were elucidated only in the process of capturing the actual
29 circuit design for FC Venus.
30
31 2.1. Set of signals
32
33 The set of UART interface signals implemented on FC Venus will be the same as
34 listed in FC Handset Specification section 1.12.1. We have a total of 5 signals
35 running from Calypso outputs to FT2232D, and a total of 4 signals running from
36 FT2232D to Calypso inputs.
37
38 2.2. Buffer ICs
39
40 Two Nexperia LVC family buffer ICs will be used on FC Venus for the purpose of
41 ferrying our set of UART interface signals between the two domains. These two
42 ICs are U401 (74LVC125A) in the mobile domain and U705 (74LVC541A) in the USB
43 domain.
44
45 U401 is powered from the mobile domain's Vio rail, and it serves only the 4
46 signals running from FT2232D to Calypso inputs, neatly using all 4 slots of
47 74LVC125A. This LVC buffer serves as a barrier, preventing feeding of power
48 from USB domain outputs into the Calypso+Iota chipset's Vio rail in the PPD
49 scenario where a USB host is connected, but the charging switch is off or the
50 battery is critically low and undergoing precharge, with the chipset switched
51 off.
52
53 No corresponding mobile domain buffers will be used for Calypso outputs: these
54 5 signals will be connected directly between Calypso pads and the interdomain
55 interface, where they will go to U705.
56
57 On the USB side, U705 will be powered from a USB domain 3.3V rail, i.e., the
58 output of a 3.3V regulator powered from USB. (This USB domain supply will be
59 the only part of FC Venus board using 3.3V - there are no regulated voltages
60 higher than 2.8V in the mobile domain.) The 8 slots of this 74LVC541A buffer
61 are split between 5 serving the Calypso to FT2232D signal direction and the
62 other 3 serving FT2232D to Calypso signals.
63
64 The purpose of the 5 U705 buffer slots serving the Calypso to FT2232D signal
65 direction is to stop the flow of current out of Calypso UART and GPIO outputs
66 in the "normal mobile usage" PPD scenario when there is no USB host connected.
67 With this buffer present, Calypso UART outputs will "see" a high impedance and
68 won't source any battery-drawn current (beyond leakage of about 0.1 uA typical
69 per pin, according to Nexperia datasheet), no matter whether the USB domain is
70 powered or not. OTOH, if this buffer were omitted and Calypso outputs were
71 connected directly to FT2232D inputs, the latter inputs would appear as shorts
72 to ground when USB power is absent, putting an unacceptable load on Calypso
73 outputs.
74
75 The other 3 slots of U705 serve FT2232D-to-Calypso signals TxD, DTR and TxD2.
76 On these 3 signals there are pull-up resistors to VBAT in front of U401 inputs
77 (see section 2.4), and the U705 buffer's Ioff feature will allow those pull-up
78 resistors to work as intended. If these pulled-up-to-VBAT nets going to U401
79 inputs were sourced directly from FT2232D outputs without going through U705,
80 the powered-off FT2232D chip's I/O pins would present a lower resistance to GND
81 than the pull-up to VBAT, drawing excessive current from the battery and making
82 the pull-up ineffective.
83
84 There is just one FT2232D-to-Calypso UART interface signal that does not go
85 through U705, and it is RTS. It has a pull-down resistor to GND instead of a
86 pull-up to VBAT in front of its U401 input. With only 8 signals rather than
87 all 9 needing to go through a USB domain LVC buffer, the 8 slots of a single
88 74LVC541A IC become sufficient.
89
90 2.3. UART signals from Calypso to FT2232D
91
92 In the case of these 5 signals running from Calypso outputs to U705 inputs, one
93 very noteworthy detail is that there are _no_ pull-up or pull-down resistors on
94 these nets. When the Calypso+Iota chipset is switched on, all 5 Calypso outputs
95 will be actively driving and there are no problem issues. However, in the PPD
96 scenario where a USB host is connected, but the Calypso+Iota chipset is switched
97 off (the charging switch is off or the battery is precharging), the absence of
98 pull resistors suggests that U705 inputs will be floating, which certainly looks
99 bad at first glance.
100
101 However, a more detailed analysis shows that floating CMOS inputs aren't bad
102 "in principle", but instead they are bad when they can float around the input
103 switching threshold, causing potential oscillations and high current draw from
104 the buffer's Vcc supply. And in the present case, the Mother's analysis
105 suggests that the signals in question won't float around the switching threshold
106 - instead we expect them to be sensed as a consistent logic low in the PPD
107 scenario in which they appear to float.
108
109 In this PPD scenario, the Iota chip's VRIO regulator is off, thus the Vio rail
110 will be at 0 V unless something feeds wayward power into it. Calypso chip
111 outputs connected to the signal nets under consideration have clamping diodes
112 to this Vio rail. Therefore, if a stray voltage somehow accumulates on those
113 nets that is high enough to approach the LVC buffer's input switching threshold,
114 it will also be high enough to drain to Vio through Calypso I/O pad clamping
115 diodes, and ultimately to GND.
116
117 What is our reason for not adding pull-up or pull-down resistors to these nets?
118 Besides the obvious reason of not wanting to throw even more PCB real estate at
119 this already way overcomplicated USB-serial interface arrangement, each of the
120 two options (pull-up or pull-down) would introduce its own problems.
121
122 The pull-up resistor option has already proven to be problematic on the
123 DUART28+Caramel2 combo, particularly in the Luna configuration in which both PPD
124 scenarios become real. When the Calypso+Iota chipset is on but there is no USB
125 power present, current from Calypso outputs flows backwards through these
126 pull-up resistors and feeds into the USB domain's power rail to which these
127 resistors are connected. The USB domain output buffer then powers up
128 erratically, feeding garbage to Calypso inputs and preventing Calypso from
129 entering sleep modes. And in the opposite PPD scenario (USB power present,
130 chipset switched off), enough power can flow through these resistors into
131 Calypso I/O pad clamping diodes to feed into Vio and cause erratic LED
132 behaviour! And on FC Venus we would have the additional problem of not having
133 a USB-powered 2.8V regulator, as we don't need it for anything else.
134
135 Pull-down resistors to GND would be much less problematic. However, if we use
136 a resistor value that is low enough to be better than floating, such as the
137 "canonical" 100 kOhm, we would be introducing a *continuous* drain on the
138 battery in normal operation. Calypso outputs corresponding to host RxD, RxD2,
139 DCD and RI will normally be high, thus each of those would be a 28 uA drain.
140 All 4 combine into a 112 uA continuous drain for no good justification, always
141 present whether or not there is a USB host connected, unlike the other similar
142 drain discussed in section 2.4. Therefore, the Mother's decision is to do away
143 with pull resistors in either direction, and hope that my reasoning is correct
144 in that we won't get prolonged floating voltages around the input switching
145 threshold.
146
147 Because these seemingly-floating nets are expected to be sensed as logic low,
148 the same logic low will be propagated to FT2232D inputs, which means a break
149 condition on RxD and asserted state on all control signals. For this reason
150 the Mother's earlier software recommendation still holds: when operating in this
151 scenario, only operate on the second UART channel (the data leads only one that
152 also has boot controls), and don't open the AT command UART channel except when
153 the mobile is switched on and regular operational firmware runs normally.
154
155 2.4. Pull-up resistors to VBAT
156
157 Experience with Caramel2 boards shows that Calypso UARTs don't like seeing a
158 break condition presented to them for extended lengths of time, thus we need to
159 design our FC Venus USB-serial interface in such a way that when there is no USB
160 host present, Calypso inputs RX_MODEM and RX_IRDA will receive high levels
161 (meaning RS-232 idle) rather than low (meaning RS-232 break). Having an
162 extended break condition presented to UARTs prevents entry into Calypso sleep
163 modes, which is obviously bad. The practical implication is that U401 inputs
164 which this buffer propagates to Calypso RX_MODEM and RX_IRDA need to be have
165 some kind of mobile domain pull-ups on them, as opposed to floating or pulled
166 down. Less critically, we do the same for the DTR signal running from the USB
167 domain to the mobile domain - thus DTR will be seen as negated when there is no
168 USB host connected.
169
170 However, if we were to implement pull-ups to the Calypso+Iota chipset's Vio rail
171 on these nets, we would have a problem in the PPD scenario of USB power present,
172 chipset switched off: U705 high outputs would feed power into Vio through these
173 resistors, potentially causing Calypso peripherals to turn on erratically as
174 has been observed on Caramel2 boards. Therefore, we are making a more unusual
175 innovation: instead of pull-ups to Vio, we are implementing pull-ups to VBAT,
176 i.e., to the unregulated raw positive battery terminal. The resistor value
177 chosen by the Mother is 22 kOhm, and the rest of this section explores the
178 implications of this unusual design under all expected conditions.
179
180 First let us examine what happens in the case of "normal" mobile usage: the
181 device is untethered and mobile, powered by the battery, and there is no USB
182 host or charger connected. In this case the input voltage seen by U401 will be
183 raw VBAT, which will always be higher than its 2.8V supply (but still safely
184 below the 5.5 V limit), thus the LVC buffer will sense a good logic high as
185 desired. The current drawn from the battery through these pull resistors will
186 be the sum of U705 Ioff and U401 Ii, each of which is listed as 0.1 uA typical
187 in Nexperia datasheets. The listed worst case specs are 10 uA for Ioff and 5 uA
188 for Ii, thus under presumably very rare conditions, we could have a maximum
189 current draw of 15 uA per each of the 3 pull-ups. 15 uA times 22 kOhm equals a
190 voltage drop of 330 mV, thus U401 inputs will remain at 2.8 V or above (meaning
191 no increased Vio supply current draw) with the battery as low as 3.1 V, which
192 is below the operational range for the mobile.
193
194 Now consider what happens when USB power is plugged in, either a host computer
195 or a charger. FT2232D will power up in UART mode and start putting out logic
196 high on all of its outputs (the state when no one opens either of the two serial
197 ports in host computer software); U705 will also power up and start putting out
198 the same logic high on the 3 signal nets going to the mobile domain. At this
199 point U705 output pads are no longer in their Ioff state, instead they are in
200 the actively driving high state, and Nexperia datasheet says that the voltage
201 at these output pins should not exceed Vcc, which is 3.3 V in the present case.
202 VBAT can be as high as 4.2 V, thus we are operating the 74LVC541A under somewhat
203 adverse conditions.
204
205 The undesirable adverse condition is that current will flow through the LVC
206 buffer's output p-channel MOSFET (open for driving high) in the wrong direction.
207 The maximum magnitude of this current is about 41 uA, computed as
208 (4.2-3.3 V) / 22 kOhm. This current magnitude is expected to be far too low to
209 damage the 74LVC541A IC (the limiting values Iok spec is 50 mA), thus the only
210 remaining concern would be feeding of a higher voltage into the USB domain's
211 regulated 3.3V rail. This concern is addressed in the following subsection.
212
213 Aside from the issues of reverse current flow through the LVC buffer's output
214 p-channel MOSFET, the other concern with this 41 uA current (at maximum VBAT)
215 is that this current is drained from the battery. With a total of 3 such
216 pull-ups, we expect a total battery drain current of 123 uA at maximum battery
217 charge - but this current only turns on when USB power is applied, and the
218 current into U705 output pins goes up from 0.1 uA to 41 uA per pin. However,
219 when USB power is applied for extended periods of time, it is usually done for
220 the purpose of charging the battery, and the charging current of 500 mA far
221 exceeds the drain current of 123 uA. In order for the battery to not be
222 charging when USB power is present, the system would have to be in one of two
223 other states: either the user connected USB for computer interface purposes and
224 not for charging (the charging switch is off), or the charge cycle finished but
225 the user hasn't unplugged the charger yet. Both of these conditions are not
226 expected to persist for unreasonably long time spans, hence the Mother deems it
227 acceptable to impose this 123 uA battery drain during times of active computer
228 interfacing.
229
230 In the case when the charging switch is on and the charging cycle has finished,
231 it is also important to consider that Iota ABB sleep is prevented for as long as
232 VCHG remains applied to the chipset, which holds whenever USB power is present
233 and the charging switch is on. In this state (charging cycle finished, but VCHG
234 not removed yet) Calypso can enter deep sleep (the main VCXO is stopped), but
235 Iota ABB sleep is prevented. According to TI's APN2_110.pdf document, the
236 difference in battery power draw between deep and "superdeep" sleep modes is
237 about 600 uA - thus leaving the charger plugged in after charge cycle completion
238 causes even more battery drain through this other mechanism than through our
239 VBAT pull-up resistors in the USB-serial interface.
240
241 Finally, whenever any of the 3 USB domain outputs in question (TxD, DTR or TxD2)
242 drives low, the current drawn from VBAT on that net increases from 41 uA to
243 about 190 uA at maximum VBAT, computed as 4.2 V / 22 kOhm. However, this
244 condition only occurs when the operator does active host computer interfacing
245 with software (the main AT command UART needs to be opened in order for DTR to
246 go low, and each of the two TxD lines goes low only when the host computer
247 actively transmits bytes), thus this increased battery current draw corresponds
248 to explicit user activity, rather than something that happens on its own. In
249 contrast, typical user activity on an untethered phone involves the LCD and its
250 backlight turning on, consuming tens of mA instead of hundreds of uA.
251
252 It also needs to be noted that all of these currents are drawn directly from the
253 battery without going through Iota LDO regulators, thus none of these uA numbers
254 come out of the 1 mA sleep mode Vio current budget.
255
256 2.4.1. USB domain 3.3V load resistor
257
258 One concern raised in the analysis of VBAT pull-ups is that when current flows
259 from the battery into the USB domain's P_3V3 rail through U705 outputs in
260 reverse, the effect may be to raise that rail above 3.3 V. To prevent this
261 effect, the Mother's idea is to add a load resistor to the USB domain, a
262 3.3 kOhm load permanently placed between P_3V3 and GND, producing a permanent
263 1 mA draw from USB, going through our 3.3V regulator. For comparison, FT2232D
264 is said to draw about 30 mA of supply current, although the datasheet does not
265 specify how it breaks down between Vcc and Vccio supply currents, hence most of
266 this 30 mA is probably drawn directly from USB 5V, without going through our
267 3.3V regulator. The addition of 1 mA to the overall USB current draw can be
268 considered insignificant (especially for 500 mA charging, but even for 30 mA
269 host computer interfacing), but with a guaranteed load of at least 1 mA on
270 P_3V3, any wayward current coming from the battery (123 uA maximum) will always
271 be absorbed into this load without raising P_3V3 above its intended 3.3 V.
272
273 2.5. Pull-down to GND on Host_RTS
274
275 The effect of Host_RTS being sensed as low instead of high when there is no USB
276 host connected is that any unsolicited output on the AT command channel will be
277 flushed in this no-host-connected state, instead of being buffered in the
278 mobile. Given that an end user mobile phone (as opposed to a dedicated cellular
279 modem) is expected to be untethered most of the time, having buffered output
280 accumulate while waiting for a host computer to be connected "some day" does not
281 sound like a good idea, hence having it flushed by unblocked flow control state
282 soundly appears to be the better option. And with only 3 out of the 4 FT2232D
283 to Calypso signals needing pull-ups to VBAT, only 3 need U705 buffer slots,
284 making a single 74LVC541A buffer IC sufficient for both directions in the USB
285 domain.
286
287 The value of the pull-down resistor on the Host_RTS net (running from FT2232D
288 ADBUS2 output to U401 input) will be 47 kOhm. When USB power is applied but no
289 one opens the AT command UART channel, FT2232D will drive its RTS output high,
290 sourcing about 70 uA of current from its USB 3.3V supply into the pull-down
291 resistor - well within FT2232D output current sourcing budget.
292
293 3. Boot control signals
294
295 The two boot control signals RPWON and nTESTRESET properly belong in the mobile
296 domain. They are pulled up to VBAT inside the mobile domain (RPWON is pulled up
297 to VBAT inside the Iota chip, nTESTRESET is pulled up to UPR with R208 per
298 Leonardo schematics), many other designs don't provide any way at all for these
299 signals to be pulled down, but on FC Venus we have a dual OD buffer (74LVC2G07)
300 in the USB domain that can pull either signal down on host command. This dual
301 OD buffer is little different from a pair of dry contact pushbutton switches
302 shorting to GND, thus the two boot control signals don't bring on any of the
303 difficulties like those associated with the UART interface.