FreeCalypso > hg > freecalypso-schem2

comparison minnie/doc/Design-spec @ 97:269b330ac428

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
minnie/doc/Design-spec: beginning of document
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 01 Oct 2023 07:01:56 +0000
parents
children 3ab69117b09f
comparison
equal deleted inserted replaced
96:ae6951a70d2b 97:269b330ac428
1 FreeCalypso Minnie GSM MS development board
2 Design specification
3
4 0. Purpose
5
6 FC Minnie board is being produced for one primary purpose: to provide an
7 alternative to the horrible (in the opinion of the Mother of FreeCalypso)
8 GTM900-based application board design being developed by Sysmocom in the
9 project identified as OS#4030. A situation in which the Horribilis board is
10 readily and cheaply available to the worldwide GSM hacker/enthusiast community
11 yet no better alternatives are available would be an unacceptable travesty,
12 hence I (Mother Mychaela) feel a moral imperative to develop, produce and make
13 available a better board, even though this venture will almost certainly come
14 at a loss in economic terms.
15
16 1. Overview of proposed new board
17
18 FC Minnie will be a single PCBA featuring the following key components:
19
20 * FC Tango module containing the Calypso GSM MS core;
21 * RF plumbing, terminating in a standard SMA female connector hanging off
22 the edge of the board;
23 * A standard SIM 2FF socket;
24 * A USB subsystem built around FT2232H, providing two UART channels behind
25 a single USB device.
26
27 The principal way of operating this board will be via USB-carried UARTs: the
28 operator will need to connect USB between her computer and FC Minnie board, and
29 two ttyUSB devices will appear, corresponding to Calypso Modem and IrDA UARTs.
30
31 FC Minnie is intended to be a GSM MS board of modem rather than handset type:
32 there are no hw provisions for connecting phone UI peripherals such as an LCD
33 or a keypad, and the board is NOT designed to operate untethered, without a
34 host computer connected via USB. FreeCalypso family of projects includes a
35 plan for a different GSM MS board, named FC Venus, that will be designed to run
36 untethered with a 176x220 pixel LCD and a keypad matching the legendary
37 historical D-Sample board from TI - but FC Venus will be an expensive board,
38 reserved for those who truly share the Mother's vision for FreeCalypso, and
39 cannot compete with the OS#4030 application board coming out of Sysmocom.
40
41 1.1. Powering arrangement
42
43 The board will consist of two separate power domains: GSM and USB. The GSM
44 domain will require a separate power supply, and cannot be powered from USB.
45 The battery-emulating power supply for the GSM MS core will be the same as used
46 for FCDEV3B and Caramel2 boards, with the same FC-standard power connector.
47 FreeCalypso HQ already has a large batch of these power supplies that were made
48 for us on a semi-custom basis, and we can provide them at a cost of about $7
49 per unit - hence from the cost perspective, there is no justification for
50 breaking FreeCalypso tradition and changing the design to a different powering
51 arrangement,
52
53 OTOH, USB will be the sole source of power for the FT2232H subsystem - if there
54 is no USB host connected, this subsystem will be unpowered.
55
56 1.1.1. Power domain boundary crossing
57
58 With USB and GSM sides of the board separately powered, there are two partial
59 power-down (PPD) scenarios to be concerned with:
60
61 PPD1: The USB host is plugged in, but there is no battery-emulating power supply
62 connected, or the GSM MS power supply is connected, but the chipset is in its
63 switched-off state per Iota VRPC.
64
65 PPD2: The GSM MS power supply is connected and the chipset is switched on in the
66 soft power switching sense, but there is no USB host connected and the FT2232H
67 subsystem is unpowered.
68
69 PPD2 is an error case: because this board is not designed to operate untethered,
70 the combination of booting the Calypso chipset and its flashed firmware without
71 a connected USB host is invalid. However, this combination can happen very
72 easily by mistake, hence the hardware needs to handle it without entering a
73 state in which it would be subjected to serious adverse conditions such as
74 excessive current flow. OTOH, PPD1 is a scenario that is expected to occur all
75 the time in standard FreeCalypso workflows: the USB host is connected but the
76 chipset has not been commanded to switch on yet, or the GSM MS has executed a
77 soft poweroff but the USB host hasn't been unplugged yet.
78
79 The set of LVC buffers inserted between FT2232H and Calypso I/O pins is expected
80 to provide correct graceful handling of both PPD scenarios, as detailed in
81 section 2.1.
82
83 1.2. FT2232H USB subsystem
84
85 Standard FreeCalypso workflows require that both Calypso UARTs be connected to
86 the development host side by side. In the olden days of TI's own developers
87 working in TI offices with D-Sample and earlier development boards, the GSM MS
88 board would bring out two DE9F RS-232 ports, engineers had desktop PCs outfitted
89 with special multiport serial cards, and there was a pair of RS-232 cables for
90 each GSM MS development board. In the present day USB is a much more practical
91 alternative, and the need to have both Calypso UARTs presented to the developer
92 side by side translates into a requirement for a two-channel USB-serial chip
93 that goes from one USB device to two UART channels. Additional requirements
94 for this two-channel USB-serial chip are:
95
96 * The two channels should be symmetric from the chip's PoV, so that the choice
97 of which channel goes to which Calypso UART can be made by FreeCalypso
98 convention. The latter convention says that in the absence of other ttyUSB
99 devices, ttyUSB0 shall be Calypso Modem UART (AT command channel) and ttyUSB1
100 shall be Calypso IrDA UART (rvinterf channel).
101
102 * The USB-serial chip needs to support non-standard baud rates, including an
103 ability to handle 203125/406250/812500 bps, and this support should be
104 available on both channels, so that no additional constraints are imposed on
105 possible developer workflows.
106
107 Out of the repertoire of USB-serial chips which I (Mother Mychaela) am familiar
108 with, only FT2232x (either FT2232C/D or FT2232H) fit the bill. My original
109 preference was for FT2232D, but that chip has just been discontinued, thus
110 FT2232H will have to be used instead.
111
112 1.3. Tango module signal bring-out trade-offs
113
114 The complete set of signals coming out of FC Tango module via its 80-pin system
115 interface connector is very rich, with most Calypso and Iota chipset signals
116 included. Caramel-type boards (iWOW DSK and FC Caramel2) make all of these
117 signals accessible for play, with most of them going to the expansion interface
118 on a 56-pin header - but these boards cannot compete for the lowest possible
119 cost market niche. Therefore, a board that is intended to compete with the
120 Horribilis board of OS#4030 on the metric of cost needs to be reduced in scope,
121 giving up advanced capabilities of FC Tango and providing only basic, modem-type
122 GSM MS functionality.
123
124 Out of the rich signal set coming out of FC Tango, only two non-essential
125 interfaces are brought out on FC Minnie: the main analog audio channel (see
126 section 2.7) and Calypso MCSI for digital audio (see section 2.8). Those who
127 are interested in additional Calypso+Iota chipset signals available on FC Tango
128 will need to use a Caramel2 board, for as long as those remain in surplus, to be
129 succeeded later by another board tentatively named EvaTango, following TI's
130 original naming convention for component evaluation boards.
131
132 2. Detailed design
133
134 2.1. Dual UART interface across power domains
135
136 2.1.1. Signals from FT2232H to Calypso
137
138 There are 4 signals that need to connect in this direction (names from host DTE
139 perspective): TxD, RTS, DTR and TxD2. If these signals were to be connected
140 directly between the two chips, there would be undesirable effects:
141
142 * FT2232H I/O operates at 3.3V; this voltage level is acceptable for Calypso I/O
143 pins (CAL000/A spec says VDDS + 0.5 V, accounting for the forward drop voltage
144 of clamping diodes inside the chip), but is not ideal.
145
146 * The main issue is partial power-down scenario PPD1, defined in section 1.1.1.
147 If the outputs of a powered USB-serial chip are connected directly to I/O pins
148 of an unpowered Calypso, current would feed from these outputs through Calypso
149 I/O clamping diodes into the Calypso+Iota chipset's V-IO rail. Series
150 resistors can limit this current to a safe value, but we now know through
151 experience that the only way to produce correct indicator LED behaviour is to
152 eliminate this wayward current completely.
153
154 The solution is to insert an LVC buffer IC (either 74LVC125A or 74LVC541A) into
155 these 4 signal paths; this buffer IC needs to be powered from the Calypso+Iota
156 chipset's V-IO rail, which is brought out from FC Tango module. With this LVC
157 buffer and the Calypso chip's I/O ring powered by the same supply rail, there is
158 no power domain boundary at Calypso inputs, and instead this boundary is moved
159 to the inputs of the LVC buffer. Unlike Calypso and other common ASICs, LVC
160 logic ICs have special input and output structures that are specifically
161 designed for PPD applications, with a guaranteed very low Ioff spec. LVC logic
162 family is also specifically designed to tolerate input voltages higher than the
163 IC's own supply, up to 5V - thus our 3.3V is well within safe design margins.
164
165 Buffer-translated DTR signal will go to Calypso GPIO3 per conventions of TI,
166 iWOW and FreeCalypso. A 2.2 kOhm series resistor can be inserted in this path,
167 solely to protect the hardware from software misconfiguration, in case someone
168 erroneously configures this Calypso GPIO as an output.
169
170 No pull resistors will be placed on the nets running from FT2232H outputs to
171 LVC buffer inputs. In erroneous scenario PPD2 all LVC buffer inputs in this
172 direction and thus all Calypso UART inputs will sense logic low: LVC buffer
173 inputs appear at first glance to be floating, but they cannot reach anywhere
174 near the switching threshold, as any accumulated stray voltages will discharge
175 toward GND through the unpowered FT2232H chip's clamping diodes.
176
177 Having Calypso UART inputs sense low rather than high is not desirable, but
178 scenario PPD2 can only be an error case on this board, hence there is no
179 justification to expend more components and PCB real estate on a more
180 complicated circuit design (see FC Venus for example) that would produce logic
181 high levels at Calypso UART inputs in this scenario.
182
183 2.1.2. Signals from Calypso to FT2232H
184
185 There are 5 signals that need to connect in this direction (names from host DTE
186 perspective): RxD, CTS, DCD, RI and RxD2. Just like in the case of signals
187 going the other way, connecting these signals directly between the two chips
188 would be problematic:
189
190 * Scenario PPD2: clamping diodes in the unpowered FT2232H chip will turn that
191 chip's inputs (driven by Calypso outputs) into shorts to GND, thus Calypso
192 outputs would be severely overloaded with high current flow. This scenario
193 is an error condition, but because it is very easily caused, we would rather
194 not overstress the hw in this condition.
195
196 * Scenario PPD1: experience with Caramel2 boards shows that pull-up resistors
197 on USB-UART inputs, including internal pull-ups inside FT2232x chips, can
198 sometimes leak enough current into the clamping diodes of directly connected
199 Calypso I/O pins to create visibly incorrect state on indicator LEDs.
200
201 The solution is to insert an LVC buffer IC (74LVC541A is needed here) into these
202 5 signal paths as well. Which supply should this buffer IC be powered from:
203 Calypso V-IO or USB domain 3.3V? Either option is expected to solve the LED
204 problem in scenario PPD1 (no path for current from the USB domain to flow into
205 the V-IO rail), but other considerations differ:
206
207 * If this LVC buffer is powered from Calypso V-IO, all FT2232H inputs will sense
208 logic high (from the chip's internal pull-ups) in scenario PPD1. However,
209 the high current problem of scenario PPD2 is not only left unsolved, but made
210 potentially worse, as LVC buffers have much higher drive strength than Calypso
211 outputs.
212
213 * If this LVC buffer IC is powered from USB domain 3.3V rail, scenario PPD2 is
214 solved: the interface between power domains occurs at a point where outputs
215 from one domain hit Ioff-specified LVC buffer inputs in the other domain.
216 However, in scenario PPD1 all FT2232H inputs will sense logic low rather than
217 high: the LVC buffers will sense logic low inputs by the same seemingly-
218 floating mechanism as in the previous section, and they will propagate this
219 logic low to FT2232H inputs.
220
221 Logic low at LVCMOS-level (as opposed to RS-232 levels) UART inputs means a
222 break condition on the data line and asserted state for all control signals.
223 Having this state at host UART input when the target is unpowered and waiting
224 to be switched on is counter to usual conventions, but creating the opposite
225 (more conventional) state in this scenario without causing any other problems
226 with the interdomain interface would require significant extra circuit
227 complexity, translating into extra cost. Thus breaking some customary
228 conventions about UARTs appears to be the appropriate compromise here.
229
230 2.2. Indicator LEDs
231
232 There will be 3 indicator LEDs on FC Minnie board: one green, one yellow and
233 one red, described in the following sections.
234
235 2.2.1. Green power-on status LED
236
237 FCDEV3B features a green LED that lights when the Calypso+Iota chipset is
238 switched on and goes out at other times. The way in which this LED is
239 implemented on FCDEV3B is completely impervious to wayward current feeding into
240 the V-IO rail, hence the issue of this current feeding from USB power domain
241 never caused a problem on that board. However, the method used on FCDEV3B
242 cannot be used on any board using a packaged modem module like iWOW-based Tango
243 or Huawei GTM900: the internal signal used for LED control on FCDEV3B is not
244 brought out by anyone.
245
246 The plan for FC Minnie is to control the green LED with V-IO. Putting a LED
247 plus a series resistor directly between V-IO and GND (powering the LED from
248 V-IO) would be a bad idea: when the Calypso+Iota chipset enters superdeep sleep,
249 the current budget of Iota regulator VRIO reduces to just 1 mA, which is too
250 little for a LED. The plan for FC Minnie is to control this LED with the same
251 "digital transistor" (BJT plus bias resistors) circuit as used for the PWL LED
252 on Caramel2 (see section 2.2.3), but with V-IO in the place of PWL signal.
253 With 10 kOhm base resistor the load on V-IO is limited to 280 uA, yet the LED
254 (powered from raw VBAT) gets enough current to be visibly lit.
255
256 In order for this plan to produce the desired result of this LED lighting when
257 the Calypso+Iota chipset is switched on and going out upon soft poweroff, there
258 must not be _any_ wayward current feeding into the V-IO rail from the USB power
259 domain by any path. The Mother's hope is that the buffer design of section 2.1
260 will work as intended and give us a reliable switch-on state indicator LED.
261
262 2.2.2. Yellow CLK13M status LED
263
264 FC Caramel2 board introduced an innovation: a yellow LED that lights when CLK13M
265 (brought out on FC Tango) is running and goes out when this clock is stopped
266 (chipset off or in deep sleep), causing this LED to flash when standard
267 FreeCalypso firmware with all sleep modes enabled is in idle mode listening on
268 PCH. Unfortunately on some Caramel2 boards this LED would also light
269 erratically in scenario PPD1: when the V-IO rail rises above 0V as a result of
270 wayward current feeding while other Calypso power supplies are off, sometimes
271 Calypso outputs behave erratically, and some may unexpectedly drive high,
272 causing LEDs to turn on.
273
274 The plan is to replicate the CLK13M status LED circuit from Caramel2 verbatim
275 on FC Minnie; the hope is that the new design of section 2.1 will eliminate the
276 problem of wayward V-IO feeding and the LED will become fully reliable.
277
278 2.2.3. Red PWL LED
279
280 The remaining LED from FC Caramel2, a red LED controlled by Calypso PWL output,
281 will also be copied verbatim on FC Minnie, and the same hope as in section 2.2.2
282 applies here too.
283
284 Calypso PWL allows the intensity of light to be smoothly controlled by software,
285 and standard FC firmware exports this control to the user in the form of AT@PWL
286 command. AT@PWL=0 turns this LED off, AT@PWL=255 turns it on at full
287 brightness, and all intermediate levels produce intermediate brightness.
288
289 2.3. Target boot control
290
291 FC Tango module brings out PWON and RESET boot control signals, although no
292 RPWON. FC Minnie will provide both manual (tactile switches) and programmatic
293 boot control options. There will be two manually operated buttons on the board,
294 PWON and RESET, and there will also be support for programmatic boot control
295 like on DUART28C.
296
297 DUART28C-style host-based boot control mechanism repurposes otherwise unused
298 RTS and DTR outputs of FT2232x Channel B, the UART channel that goes to the
299 data leads only Calypso debug UART. The circuit consists of a pair of OD
300 drivers packaged in one 74LVC2G07 chip, with RTS driving PWON and DTR driving
301 RESET.
302
303 Correct operation with these circuit connections in place requires programming
304 a custom USB ID code into FT2232x EEPROM (see section 2.4) and patching the
305 Linux kernel ftdi_sio driver to apply a special quirk upon seeing this USB ID.
306 An additional complication is that Linux USB and tty subsystem maintainers are
307 refusing to mainline this quirk-adding patch, thus end users need to apply this
308 patch on their own systems in an act of principled defiance against obstinent,
309 assinine and tyrannical maintainers.
310
311 Because of these complications, this DUART28C-style boot control circuit needs
312 to be made optional. The simplest solution is a pair of jumpers: the net from
313 the OD driver on Channel B RTS to Tango PWON will pass through one user-
314 removable jumper (2.54 mm header pin pair with a removable shorting block), and
315 the net from the OD driver on Channel B DTR to Tango RESET will pass through
316 another such jumper.
317
318 2.4. FT2232H USB subsystem details
319
320 The USB connector will be of mini-B type like on all other classic development
321 boards targeting this hacker community; the circuit from this USB connector to
322 FT2232H chip will be as prescribed by FTDI. An external LDO regulator bringing
323 the bus-powering voltage from 5V down to 3.3V will need to be implemented, as
324 always required with FT2232H, and all components are then powered from this 3.3V
325 supply.
326
327 The FT2232H subsystem will include a 93C46 EEPROM. FT2232H can work without an
328 EEPROM, but I as the Mother of FreeCalypso insist on always including this
329 configuration EEPROM. FC Minnie will need to have a custom USB ID programmed
330 in this EEPROM when the two remote boot control jumpers are installed, and with
331 both PID options the EEPROM will always be programmed with custom textual ID
332 strings, allowing the board to be recognized among other USB devices sharing
333 the same VID:PID.
334
335 2.5. RF plumbing
336
337 2.6. SIM socket
338
339 2.7. Analog audio
340
341 2.8. Digital audio
342