FreeCalypso > hg > fc-small-hw

comparison fc-uja/design-spec @ 0:0f9bdd60ce50

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
fc-small-hw separated from old freecalypso-schem repo
author Mychaela Falconia <falcon@freecalypso.org>
date Mon, 21 Oct 2019 00:53:38 +0000
parents
children
comparison
equal deleted inserted replaced
-1:000000000000 0:0f9bdd60ce50
1 FreeCalypso UART+JTAG Adapter
2 Board design specification
3
4 1. Purpose and scope
5
6 The circuit board described in this specification will be an adapter for
7 connecting a host PC or laptop (via USB) to the following 3 development
8 interfaces on FreeCalypso GSM devices:
9
10 * A 3-wire UART interface intended for RVTMUX on Calypso's IrDA UART
11 * Calypso JTAG
12 * Iota nTESTRESET
13
14 The core function of interfacing from USB to a UART, JTAG and GPIO will be
15 performed by an FT2232D chip, but the board described herein has two key
16 differences from a generic FT2232x board, key differences which necessitate the
17 development of a custom board:
18
19 * Our board will have 3-state buffers on the JTAG lines and an open drain
20 driver on the nTESTRESET line, wired in such a way that they cannot be
21 accidentally turned on while the FT2232D is in its power-up default UART
22 mode, prior to the software switch into the MPSSE+GPIO mode.
23
24 * The target connection interface will be presented not only on general-purpose
25 headers, but also on a special FFC connector, to be used with our future
26 FreeCalypso handset boards that will use the FFC-based development interface
27 copied from Foxconn's Pirelli DP-L10 phone.
28
29 The gadget to be built is intended to serve the following two purposes, in this
30 order of importance:
31
32 Application 1: the present adapter will be required to do initial bring-up,
33 deep development and production-time programming and testing on our upcoming
34 FreeCalypso handset boards. Calypso's MODEM UART will be wired to the handset's
35 built-in USB-serial port also acting as the charging power source, but that
36 interface is intended for end users - deep development, initial bring-up and
37 production processes will need to be done through the IrDA UART wired to the
38 FFC interface through the present adapter. JTAG is not expected to be needed,
39 but is "thrown in for free" - however, the Iota nTESTRESET line will be very
40 useful for commanding system switch-on that can be distinguished from both the
41 end user power-on button and the charger plug event, as well as for easy
42 recovery from any hung state.
43
44 Application 2: it costs us nothing extra to bring the target connection
45 interface out on generic headers in addition to the FFC connector. If anyone
46 needs to play with JTAG on our FCDEV3B or on a Motorola C1xx phone hacked up
47 with little wires, the present adapter will be more robust compared to
48 unbuffered COTS FT2232x breakout boards thanks to our 3-state buffers
49 protecting the JTAG lines from FT2232's initial UART mode garbage.
50
51 However, the present FreeCalypso UART+JTAG adapter board is NOT intended to be
52 used as a generic JTAG adapter for non-Calypso targets. The set of additional
53 signals needed besides JTAG is quite different between the two: most traditional
54 (non-GSM) ARM processors and DSPs have TRST and/or SRST signals, and sometimes
55 also DBGRQ/DBGACK - whereas the Calypso+Iota chipset has no TRST, and the way
56 Iota's nTESTRESET signal works is quite different. Companies like Tin Can Tools
57 (Flyswatter2) already provide superb-quality and very cheap FT2232x-based JTAG
58 adapters for "generic" applications, and there is no point in trying to compete
59 with them - instead we need a Calypso-specific adapter that provides a UART,
60 nTESTRESET control and JTAG in this order of priority.
61
62 2. Detailed design
63
64 2.1. FT2232D core block
65
66 The FTDI chip chosen for this adapter board is FT2232D. One of the FT2232x
67 devices is needed because we need MPSSE for JTAG plus a second channel for the
68 RVTMUX UART, leaving FT2232C/D/L and FT2232H as the two viable candidates. The
69 FT2232H high speed device does not offer anything useful for our application,
70 hence the more basic FT2232D has been chosen on the principle of "bez nadobnosti
71 nosimyj nabryushnik vreden" (a Russian proverb) - introducing USB high speed
72 capability (480 Mbps USB signaling) with FT2232H would increase the chances of
73 USB signal integrity problems due to suboptimal PCB layout or suboptimal USB
74 cable quality while providing absolutely no useful gain in our application,
75 whereas FT2232D is inherently safer in this regard by not having that USB high
76 speed capability in the first place. FT2232D is a direct drop-in for the
77 earlier FT2232C and FT2232L chips; FT2232D is a currently active part available
78 from Digi-Key whereas its predecessors are surplus-only parts.
79
80 FT2232C/D devices only support MPSSE on Channel A, hence our FreeCalypso
81 UART+JTAG adapter will follow the general canon for such adapters in that JTAG
82 and test reset will be on Channel A, whereas Channel B will be used for the
83 RVTMUX UART.
84
85 There will be a 93C46 EEPROM connected to the FT2232D chip. This EEPROM is
86 needed so that we can give our adapter a custom USB ID (out of the range of USB
87 IDs allocated by FTDI to Falconia Partners LLC); this custom USB ID is needed
88 for several reasons:
89
90 * We don't want the ftdi_sio driver in the Linux kernel to create two ttyUSBx
91 devices for both FT2232D channels only to have the first of the pair disappear
92 when a custom libftdi-based program is run to make use of JTAG and/or reset
93 functions on Channel A - instead we would like to have this driver create
94 only one ttyUSBx device for the UART on Channel B. There already exist
95 several other UART+JTAG adapters whose creators and users had the same need,
96 and the ftdi_sio driver in Linux supports them. The existing adapters of
97 this kind are identified by custom USB IDs, and once our own adapter advances
98 past the vaporware phase, we'll be submitting a one-line patch to the Linux
99 kernel driver to add our custom USB ID to the list.
100
101 * We will have a custom libftdi-based program for sending nTESTRESET to the
102 FreeCalypso GSM device target through our adapter; this program will have an
103 easier time locating our USB device among other potential FTDI-based devices
104 if we use a custom USB ID.
105
106 * When the time comes to configure OpenOCD to do JTAG through our adapter,
107 having a custom USB ID will similarly help prevent erroneous binding to other
108 FTDI-based devices that may be present.
109
110 2.2. Buffering logic for JTAG
111
112 One significant design blemish of the otherwise quite versatile FT2232D is that
113 "bit" modes like MPSSE cannot be configured in the EEPROM, instead they can only
114 be entered dynamically on software command from the host. As the result, an
115 FT2232D channel that is meant to be used for, say, JTAG on a given board will
116 still operate in its default UART mode when USB power is first applied, and will
117 remain in this state indefinitely long, until the user runs a program on the
118 host that issues a software command to enter the "bit" mode - which may never
119 happen. If an FT2232D channel is wired for JTAG but the chip operates in its
120 default UART mode, the following problems will occur if the signals are wired
121 directly without additional buffering logic:
122
123 * The ADBUS0 line which becomes TCK in JTAG mode is TxD in UART mode, and will
124 thus drive a high level on power-up - even though the quiescent state on TCK
125 should be low.
126
127 * JTAG TDO line (output from the target) needs to be connected to ADBUS2 - this
128 signal becomes an input in MPSSE mode - but in the power-up default UART mode
129 ADBUS2 is an output. Thus this default output can end up fighting with the
130 target's TDO output, potentially damaging the target, the adapter or both.
131
132 (The other two JTAG signals - TDI and TMS driven from ADBUS1 and ADBUS3 - are
133 less of a problem because in the power-up default UART mode these FT2232D pins
134 are inputs with weak internal pull-ups on them.)
135
136 Our solution to this problem is to insert 3-state buffers (unidirectional in
137 the JTAG signal direction) into all 4 JTAG lines. We shall use 3-state buffers
138 with active-low enables, and the two enable lines (one for the TCK, TDI and TMS
139 outputs from the adapter, the other for the TDO input) will come from FT2232D
140 pins ADBUS5 and ADBUS6. In the MPSSE mode used for JTAG these pins become GPIOs
141 and will need to be configured as outputs driving low in order to enable JTAG,
142 but in the power-up default UART mode they are inputs with internal pull-ups,
143 and we will have additional external pull-ups for safety. The effects will be
144 as follows:
145
146 * As long as the FT2232D channel is in UART mode, the 3-state buffers can never
147 be enabled. All JTAG outputs from the adapter will be tristated (i.e., the
148 same as if the adapter weren't there, presenting the target with its normal
149 sans-JTAG state), there will be no fighting on ADBUS2, and the UART will sense
150 all of its inputs as inactive high.
151
152 * As the MPSSE mode is entered on software command, the initial pin direction
153 mask byte should be 0x01, keeping ADBUS0 as an output, but then an MPSSE GPIO
154 command should be given, enabling the other outputs along with sensible
155 initial values.
156
157 * ADBUS6 should be driven low to enable the TDO receiving buffer (it will have
158 a weak pull-up on the buffer's input in order to not float when there is no
159 target connected) right after ADBUS2 is switched to being an input, but
160 ADBUS5 can be driven low or high at any time afterward to enable or disable
161 the JTAG outputs.
162
163 2.3. Sideband signals alongside JTAG
164
165 2.3.1. Iota nTESTRESET driver
166
167 The test reset line in the Calypso+Iota solution (nTESTRESET) is handled by the
168 VRPC block in the Iota ABB which is essentially a PMIC. It is always pulled up
169 inside the GSM device to a non-logic power rail, and this circuit works even
170 when the mobile is in the switched-off state with all of the main voltage
171 regulators for regular logic turned off. The raw nTESTRESET line is not meant
172 to ever be driven by any kind of active push-pull logic driver; instead it is
173 meant to be shorted to GND to trigger the reset, through either a pushbutton
174 switch or an OC/OD driver.
175
176 Back when TI made their x-Sample and Leonardo development boards, they
177 apparently preferred to drive their JTAG+reset test interface (14-pin header in
178 TI's JTAG pinout) with whatever generic (non-Calypso-specific) JTAG adapter
179 they already had at the time, and as their 14-pin JTAG interface was defined,
180 pin 2 (reset) was defined to be TRST with an active push-pull driver in the
181 JTAG host adapter (or "emulator" as they call it). These x-Sample and Leonardo
182 boards have a little on-board circuit between this connector pin 2 and the
183 actual nTESTRESET; this circuit consists of two transistors and has the effect
184 of protecting the internal nTESTRESET line from whatever the external driver
185 may be doing: if the external adapter drives a logic low, the transistor circuit
186 pulls nTESTRESET low via what is effectively an OC driver, otherwise the JTAG
187 block presents a Hi-Z state to the nTESTRESET line. This circuit has been
188 copied from Leonardo schematics on our own FCDEV3B, but the current plan is to
189 not include it on the handset board, instead bringing out nTESTRESET in its
190 native form on the FFC interface like the Pirelli DP-L10 board appears to do.
191
192 Our FreeCalypso UART+JTAG adapter will drive this nTESTRESET pin with an open
193 drain driver. This driving arrangement is compatible with both approaches:
194 either direct nTESTRESET connection or the transistor circuit on FCDEV3B and on
195 TI's boards. It does, however, make our adapter specific to Calypso+Iota GSM
196 devices: more generic ARM processors and DSPs will often have more standard
197 TRST and/or SRST signals instead, possibly needing active push-pull drivers.
198
199 To protect the reset line from FTDI's UART-default bogosity, the input to the
200 non-inverting open drain driver will come from ADBUS7, which is an input in the
201 FT2232D's power-up default UART mode. Like ADBUS5 and ADBUS6 controls for the
202 3-state buffers for JTAG, this ADBUS7 line will have an additional external
203 pull-up for safety, thus the reset can never be triggered accidentally while
204 the FT2232D channel is in UART mode - the only way to trigger the test reset
205 will be to first put the channel into the MPSSE+GPIO mode, then make ADBUS7 an
206 output driving low.
207
208 2.3.2. Calypso nEMU0 and nEMU1 pins
209
210 The Calypso chip has two JTAG-sideband pins called nEMU0 and nEMU1. They form
211 some kind of debug/development interface which is not needed in normal product
212 operation, and all Calypso-based GSM phone and modem product boards known to us
213 leave them unconnected - even those product boards on which the regular JTAG
214 pins are brought out (Pirelli DP-L10 and some Mot C1xx variants). TI's
215 Leonardo schematics leave them unconnected as well, but their more complete
216 x-Sample boards have them brought out to the 14-pin JTAG connector. Our
217 FCDEV3B has them brought out as well.
218
219 The problem with these nEMU0 and nEMU1 pins is that they are undocumented: the
220 docs we have only say that they are bidirectional signals with pull-ups, and
221 nothing else. We have on-board pull-ups on these two lines on our FCDEV3B
222 (copied from TI's E-Sample board) strengthening the Calypso chip's supposed
223 internal pull-ups, but we don't know what will happen if either or both pins
224 are driven low externally (at boot or any other time), nor do we know if the
225 Calypso chip itself ever drives or pulses them low as outputs. Common sense
226 suggests that one of their likely functions is probably to hold the ARM7 core
227 in the debug halt state directly out of reset, and possibly disable the
228 watchdog timer which is otherwise enabled and ticking at this time - but we
229 don't know any of the details.
230
231 Because we don't know exactly how these nEMU0 and nEMU1 pins work, the only
232 sense in which we can support them is to provide a way to use our FreeCalypso
233 UART+JTAG adapter as a reverse engineering tool, experimentally playing with
234 these nEMU[1:0] pins on an FCDEV3B. We are going to make the following simple
235 provision to facilitate such experimentation: we are going to connect FT2232D
236 pins ACBUS2 and ACBUS3 to pins 13 and 14 on the 14-pin JTAG header, which are
237 the pins for nEMU0 and nEMU1. Unlike all other signals, this one will be a
238 direct connection without any buffering. ACBUS2 and ACBUS3 function as open
239 drain LED drivers in the power-up default UART mode, and these pins have been
240 chosen on the reasoning that they are expected to stay non-driving as long as
241 no one actually opens Channel A as a UART and tries to send something through
242 it. The following important additional considerations apply:
243
244 * These nEMU0 and nEMU1 signals are NOT included in the FFC interface defined
245 by Foxconn/Pirelli which we are copying for our FreeCalypso handset boards.
246 The positive implication is that the development interface for these FC
247 handset boards will not be adversely affected by the potentially dangerous
248 unbuffered connection to FT2232D pins; the negative implication is that if we
249 ever do learn how to use these nEMU[1:0] pins to do whatever they can do,
250 that ability won't be available on the handset boards. However, the latter
251 loss is deemed to be acceptable: the most plausible function of these
252 nEMU[1:0] pins is to enter JTAG debug state directly out of reset, and we
253 don't need this ability when we have the internal boot ROM enabled via nIBOOT:
254 we can interrupt and divert the boot process serially, and then enter the
255 debug state through the regular JTAG scan chain.
256
257 * Anyone using the 14-pin JTAG header interface to connect to a target such as
258 FCDEV3B that does have nEMU0 and nEMU1 signals on pins 13 and 14 still has
259 the freedom to connect or not connect these signals as desired. With our
260 current FCDEV3B certain mechanical constraints practically impose the
261 requirement of making a custom cable in any case: the spacing between headers
262 on the FCDEV3B is too tight for standard ribbon cables terminated with IDC
263 connectors (there is no room for the bulky sides of those IDC connectors),
264 hence one needs to crimp female terminals onto individual wires and insert
265 them into a crimp housing instead. In light of these considerations, you
266 should only connect pins 13 and 14 between our adapter and your target if you
267 are specifically interested in experimenting with driving or sensing Calypso's
268 nEMU0 and nEMU1 signals, otherwise leave them unconnected.
269
270 * Our entire "support" for these nEMU[1:0] pins will consist of two PCB traces
271 connecting FT2232D's ACBUS2 and ACBUS3 pins to two pins on the 14-pin JTAG
272 header. This arrangement, which could be considered quite risky under
273 different circumstances, does absolutely nothing and cannot cause any harm if
274 those two header pins are NOT subsequently connected to an actual Calypso
275 target.
276
277 2.4. FT2232D I/O pin summary
278
279 Channel A pins will be assigned and connected as follows:
280
281 ADBUS0: JTAG TCK (fixed by FTDI)
282 ADBUS1: JTAG TDI (fixed by FTDI)
283 ADBUS2: JTAG TDO (fixed by FTDI)
284 ADBUS3: JTAG TMS (fixed by FTDI)
285 ADBUS4: unused and unconnected
286 ADBUS5: active-low output enable control for JTAG outputs
287 ADBUS6: active-low output enable control for TDO receiving buffer
288 ADBUS7: active-low nTESTRESET control
289
290 ACBUS0: unused and unconnected
291 ACBUS1: unused and unconnected
292 ACBUS2: wired to JTAG header pin 13 (nEMU0)
293 ACBUS3: wired to JTAG header pin 14 (nEMU1)
294
295 The 3 pins that are unused and unconnected (ADBUS4, ACBUS0 and ACBUS1) can be
296 configured as either inputs with internal pull-ups or outputs. For the
297 remaining pins which do have assigned functions, the following software init
298 sequence should be adhered to:
299
300 * As the MPSSE mode is entered on software command, the initial pin direction
301 mask byte should be 0x01. The critical points are to set ADBUS0 as an output
302 at this point so it never glitches through a non-driving state (it is TxD in
303 the power-up default UART mode), make ADBUS2 an input as it will need to be
304 once TDO is enabled, and set ADBUS5-7 as inputs. ADBUS5-7 need to be inputs
305 at this stage (the connected logic will sense the inactive high level from
306 pull-up resistors) because the initial output value for initialized-as-output
307 pins is not defined.
308
309 * MPSSE Set Data Bits High Byte (0x82) command should be given to set ACBUS2
310 and ACBUS3 as inputs, leaving nEMU[0:1] pins undisturbed until and unless you
311 are playing with them.
312
313 * MPSSE Set Data Bits Low Byte (0x80) command should be given to make ADBUS0
314 (TCK) an output driving 0, make ADBUS1 (TDI) an output driving 1, keep ADBUS2
315 as an input from the MPSSE mode entry step, make ADBUS3 (TMS) an output
316 driving 1, and make ADBUS6 (TDO receiving buffer control) an output driving 0.
317 ADBUS5 (JTAG output buffer control) and ADBUS7 (nTESTRESET driver) should be
318 configured as outputs at this point, but their driving values will depend on
319 the application.
320
321 Channel B will be used as a data-leads-only UART with standard wiring requiring
322 no software intervention:
323
324 BDBUS0: TxD (UART output)
325 BDBUS1: RxD (UART input)
326 the rest: unused and unconnected
327
328 2.5. Logic voltage levels and buffering
329
330 Many FT2232x-based JTAG adapters have level-translating buffers between FT2232x
331 pins and the target interface in order to support targets with different logic
332 voltage levels, usually from 3.3 V down to 1.8 V, or sometimes an even wider
333 allowed range: for example, the Flyswatter2 adapter from Tin Can Tools supports
334 target logic voltage levels from 1.6 to 5.0 V.
335
336 In our case such voltage level shifting is not really needed: Calypso is 2.8 V
337 native, but perfectly tolerant of 3.3 V inputs as well. The following
338 approaches have been considered for our FreeCalypso UART+JTAG adapter:
339
340 Approach 1: put a 3.3 V regulator on our board, run FT2232D I/O pins at 3.3 V,
341 run the 3-state buffers for JTAG at 3.3 V as well, and connect the UART lines
342 to FT2232D Channel B pins directly, without buffering. This approach relies on
343 Calypso's inputs being tolerant of 3.3 V and Calypso's 2.8 V outputs producing
344 voltage levels suitable for 3.3 V inputs. In practice this approach has already
345 been used quite extensively in other contexts: we connect Calypso I/O to 3.3 V
346 logic when we connect FCDEV3B UARTs to generic off-the-shelf FT2232x adapter
347 boards, users of headset jack serial adapters for Motorola and Openmoko phones
348 do likewise, Openmoko connected Calypso's 2.8 V UART to their 3.3 V application
349 processor, and Foxconn/Pirelli appear to have done likewise with their built-in
350 USB-serial interface based on a CP2102 chip with 3.3 V I/O.
351
352 Approach 2: put both 3.3 V and 2.8 V regulators on our board, run FT2232D I/O
353 pins at 3.3 V (the lowest I/O voltage officially supported by FT2232x chips),
354 have the inputs from the Calypso target go directly to 3.3 V logic like with
355 Approach 1, but run the 3-state buffers for JTAG outputs plus an always-enabled
356 buffer for the UART output at 2.8 V. This approach makes the adapter's outputs
357 2.8 V proper, but at the cost of an extra on-board regulator.
358
359 Approach 3: similar to Approach 2, but omit the on-board 2.8 V regulator and
360 instead power the 2.8 V output buffers from the target voltage reference pin
361 provided both on TI's 14-pin JTAG interface (used on development boards, both
362 TI's and our own FCDEV3B) and on the FFC interface we are copying from
363 Foxconn/Pirelli. Compared to Approach 2, this approach eliminates the extra
364 on-board regulator, but would cause some power to be drawn from the target to
365 power the output buffers. This approach would also create difficulties if a
366 user wishes to use the generic header interface (as opposed to the highly
367 specialized FFC interface), and there is no source from which the target
368 reference voltage pin can be supplied. A compromise approach could be
369 implemented by putting a 3-pin jumper header on our board, selecting the power
370 to the output buffers between internal 3.3 V and the external target voltage
371 reference pin, but having that jumper set to the internal 3.3 V supply would
372 effectively bring us back to Approach 1.
373
374 Approach 4: do what the "big guys" do in terms of voltage level translation:
375 use special dual-supply translating buffers in both directions, supporting any
376 target voltage level at least between 1.8 and 3.3 V or possibly wider. This
377 approach would be appropriate for a more general-purpose JTAG adapter that needs
378 to work with, say, 1.8 V targets, but given that our adapter is specific to the
379 Calypso which has 2.8V-native, 3.3V-tolerant I/O, the extra complexity of
380 full-blown voltage level translation is not really justifiable.
381
382 Approaches 3 and 4 are excessively complex and cumbersome, and cannot be
383 justified in our Calypso-specific application. The practical choice is thus
384 between approaches 1 and 2. My (Mother Mychaela's) initial leaning was toward
385 Approach 1, but upon further reflection I swayed over to Approach 2. The cost
386 of the additional on-board 2.8 V regulator in terms of PCB real estate and
387 layout complexity is not too great, and given that our adapter is very
388 specifically for the Calypso and no other targets, it makes more sense to put
389 out Calypso's native voltage levels, rather than merely compatible ones.
390
391 Approach 2 will be used on our FreeCalypso UART+JTAG adapter, with the following
392 additional nuances:
393
394 * A 74LVC125A output buffer (4 individual buffers in one package) powered from
395 the 2.8 V regulator will be used for the 4 logic outputs from our adapter:
396 JTAG outputs TCK, TDI and TMS, and the single UART output. The output enables
397 for the JTAG outputs will come from ADBUS5, whereas the UART output will be
398 always enabled.
399
400 * Another similar buffer, but powered from the 3.3 V regulator will be used for
401 the two logic signals going the other way: JTAG TDO and the UART input. The
402 buffer for TDO will be enabled by ADBUS6, the UART input will be always
403 enabled. There will be a pull-up resistor to local 2.8 V on the input
404 (target interface) side of each buffer. The buffer for TDO is needed for
405 3-state control, but an identical buffer will also be used for the UART input
406 for the sake of symmetry, and to present the target with a pull-up to 2.8 V
407 rather than FT2232D's internal pull-up to 3.3 V.
408
409 * All pull-ups on the interface between FT2232D pins and the just-described
410 buffers will be to 3.3 V.
411
412 * A dedicated 3.3 V regulator will be used, instead of trying to use the feeble
413 one built into the FT2232D, as the datasheet-stated limit of 5 mA seems like
414 too little margin.
415
416 * The only interface on which the target would ever see 3.3 V rather than 2.8 V
417 will be the purely experimental provision for Calypso nEMU[1:0] described in
418 section 2.3.2, to be used only by those who are specifically interested in
419 that line of experimentation, and not in any other use cases. It makes no
420 sense to attempt voltage level-translating buffering for these signals when
421 we don't even know if they are really inputs or outputs, and under what
422 conditions.
423
424 The target voltage reference pins on the TI-style 14-pin JTAG header connector
425 and on the Foxconn/Pirelli-style FFC connector will remain unused and
426 unconnected. One could make an argument that not using the target-provided I/O
427 voltage reference is wrong, but the issue needs to be seen in context. TI's
428 14-pin JTAG interface was designed for use in a wide range of applications,
429 covering I/O voltages at least between 1.8 and 3.3 V, and TI's XDS JTAG adapters
430 support this wide range of I/O voltages just like the ones made by community
431 vendors like Amontec and Tin Can Tools. In the case of Foxconn and their
432 Pirelli DP-L10 design, we can never know for certain, but it is highly plausible
433 that they weren't making a custom FT2232x-based JTAG adapter of their own like
434 we are doing, and instead had a passive adapter that connected their FFC
435 interface to some existing TI XDS JTAG adapter, likely via that very same 14-pin
436 interface. In that case the existing TI XDS JTAG adapter they were using needed
437 a target voltage reference pin, and so they included one in their custom FFC
438 interface. But our circumstances are different: we are making a custom
439 UART+JTAG adapter for reasons of our own, and because our custom adapter is
440 very specific to the Calypso, having our own on-board 2.8 V regulator is more
441 robust than depending on an I/O buffer supply from the target.
442
443 2.6. Target connection interfaces
444
445 2.6.1. Generic header interface
446
447 Our FreeCalypso UART+JTAG adapter will feature two header connectors: a 14-pin
448 header in TI's pinout for JTAG, nEMU[1:0] and nTESTRESET, and a separate 3-pin
449 header for the UART. This header interface option will make it possible to use
450 our adapter with the FCDEV3B, with TI's D-Sample board (JTAG+company 14-pin
451 interface only) and even with hacked-up C1xx phones with little wires soldered
452 to JTAG test pads. As explained in section 2.3.2, always give explicit thought
453 as to whether pins 13 and 14 (nEMU0 and nEMU1) should be connected or not in
454 your application.
455
456 The UART on FT2232D Channel B will be completely independent of JTAG and other
457 Channel A functions, and can be used as a completely generic data-leads-only
458 asynchronous serial interface at 2.8 V.
459
460 2.6.2. FFC interface
461
462 Our upcoming FreeCalypso handset boards will need to use an FFC interface for
463 development functions. At the very minimum this interface needs to connect the
464 Calypso's IrDA UART carrying RVTMUX, and do it in such a way that this serial
465 interface can be connected without applying a "charger present" condition to
466 the VRPC block in the Iota ABB - hence the need for an interface outside of the
467 handset's built-in USB-serial port. Furthermore, if we copy the FFC interface
468 from Foxconn's Pirelli DP-L10 design instead of inventing our own, we get not
469 only a UART channel, but also JTAG and nTESTRESET on the same interface. There
470 is very little need for JTAG in FreeCalypso, but it is certainly a nice-to-have.
471 Having the ability to drive nTESTRESET from the development host will also come
472 very useful: once we implement proper handset on/off logic in the firmware,
473 meaning that different switch-on causes will be treated like they should be in
474 a real handset, switch-on from nTESTRESET will become the development and
475 production boot mode.
476
477 Our FFC interface is effectively defined by the unpopulated FFC connector
478 footprint and its wiring found in Pirelli DP-L10 phones. It is a 12-pin FFC
479 interface with 0.5 mm pitch, the unpopulated connector footprint on Pirelli's
480 PCB has pin numbers marked on the silk screen, and the pins are assigned as
481 follows:
482
483 Pin Function
484 ----------------
485 1 V-IO rail
486 2 UART Rx (input to the target)
487 3 Iota nTESTRESET
488 4 JTAG TDI
489 5 JTAG TMS
490 6 JTAG TCK
491 7 UART Tx (output from the target)
492 8 JTAG TDO
493 9 unused
494 10 GND
495 11 unused
496 12 unused
497
498 At one time we had a plan to add Calypso nEMU[1:0] signals to this interface by
499 putting them on the last two unused pins, but this addition has been rejected
500 for the time being: because we have no documentation for what these nEMU[1:0]
501 pins do and all we can do with them are reverse engineering experiments, these
502 signals should be kept out of handset products and limited to development boards
503 like FCDEV3B for the time being.
504
505 There is, however, one critical aspect of this FFC interface which cannot be
506 recovered from the Pirelli DP-L10 artifacts and instead has to be defined anew:
507 the question of top vs. bottom orientation. Our decision process in this regard
508 begins with the availability of FFC jumpers, i.e., the flat flexible piece that
509 goes between the two boards. The FFC jumper version with same-side contacts is
510 readily available from Digi-Key as very inexpensive single pieces, but the
511 version with opposite-side contacts is only available with a prohibitely
512 expensive MOQ. Having settled on the FFC jumper with same-side contacts, we
513 are left with two options: have the contacts on both sides face upward, or have
514 them face downward. The decision between the two is completely arbitrary and
515 we have no way of knowing which way Foxconn had it back in their day, but we
516 have to decide one way or the other starting with the design of this adapter
517 board. The Mother's arbitrary decision is to have the contacts on both sides
518 of the FFC jumper face upward, meaning that:
519
520 * The FFC connector on the FreeCalypso UART+JTAG Adapter board will need to be
521 the top-side contacts version.
522
523 * If we are going to populate an FFC connector on a decased Pirelli motherboard
524 in order to exercise our adapter against that pre-existing target, the top-
525 side contacts version will need to be used. We'll need to do the same if we
526 make our own handset board on which the FFC connector is on the side with the
527 display and the main keypad buttons.
528
529 * If we make our own handset board on which the FFC connector is on the bottom
530 side of the motherboard (the side opposite the display), which is the current
531 plan, the connector will need to be the bottom-side contacts version.
532
533 Because pin 1 is on the left on the existing target board with the connector on
534 the top side (Pirelli DP-L10) and we are using the same-side jumper version that
535 flips the left/right orientation, pin 1 will need to be on the right in the
536 connector footprint definition on the adapter board.