FreeCalypso > hg > fc-small-hw
view fc-uja/design-spec @ 81:6feb6db2c0bf
sim-fpc-pasv MCL: FPC connector footprint
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Tue, 25 Oct 2022 05:13:55 +0000 |
parents | 0f9bdd60ce50 |
children |
line wrap: on
line source
FreeCalypso UART+JTAG Adapter Board design specification 1. Purpose and scope The circuit board described in this specification will be an adapter for connecting a host PC or laptop (via USB) to the following 3 development interfaces on FreeCalypso GSM devices: * A 3-wire UART interface intended for RVTMUX on Calypso's IrDA UART * Calypso JTAG * Iota nTESTRESET The core function of interfacing from USB to a UART, JTAG and GPIO will be performed by an FT2232D chip, but the board described herein has two key differences from a generic FT2232x board, key differences which necessitate the development of a custom board: * Our board will have 3-state buffers on the JTAG lines and an open drain driver on the nTESTRESET line, wired in such a way that they cannot be accidentally turned on while the FT2232D is in its power-up default UART mode, prior to the software switch into the MPSSE+GPIO mode. * The target connection interface will be presented not only on general-purpose headers, but also on a special FFC connector, to be used with our future FreeCalypso handset boards that will use the FFC-based development interface copied from Foxconn's Pirelli DP-L10 phone. The gadget to be built is intended to serve the following two purposes, in this order of importance: Application 1: the present adapter will be required to do initial bring-up, deep development and production-time programming and testing on our upcoming FreeCalypso handset boards. Calypso's MODEM UART will be wired to the handset's built-in USB-serial port also acting as the charging power source, but that interface is intended for end users - deep development, initial bring-up and production processes will need to be done through the IrDA UART wired to the FFC interface through the present adapter. JTAG is not expected to be needed, but is "thrown in for free" - however, the Iota nTESTRESET line will be very useful for commanding system switch-on that can be distinguished from both the end user power-on button and the charger plug event, as well as for easy recovery from any hung state. Application 2: it costs us nothing extra to bring the target connection interface out on generic headers in addition to the FFC connector. If anyone needs to play with JTAG on our FCDEV3B or on a Motorola C1xx phone hacked up with little wires, the present adapter will be more robust compared to unbuffered COTS FT2232x breakout boards thanks to our 3-state buffers protecting the JTAG lines from FT2232's initial UART mode garbage. However, the present FreeCalypso UART+JTAG adapter board is NOT intended to be used as a generic JTAG adapter for non-Calypso targets. The set of additional signals needed besides JTAG is quite different between the two: most traditional (non-GSM) ARM processors and DSPs have TRST and/or SRST signals, and sometimes also DBGRQ/DBGACK - whereas the Calypso+Iota chipset has no TRST, and the way Iota's nTESTRESET signal works is quite different. Companies like Tin Can Tools (Flyswatter2) already provide superb-quality and very cheap FT2232x-based JTAG adapters for "generic" applications, and there is no point in trying to compete with them - instead we need a Calypso-specific adapter that provides a UART, nTESTRESET control and JTAG in this order of priority. 2. Detailed design 2.1. FT2232D core block The FTDI chip chosen for this adapter board is FT2232D. One of the FT2232x devices is needed because we need MPSSE for JTAG plus a second channel for the RVTMUX UART, leaving FT2232C/D/L and FT2232H as the two viable candidates. The FT2232H high speed device does not offer anything useful for our application, hence the more basic FT2232D has been chosen on the principle of "bez nadobnosti nosimyj nabryushnik vreden" (a Russian proverb) - introducing USB high speed capability (480 Mbps USB signaling) with FT2232H would increase the chances of USB signal integrity problems due to suboptimal PCB layout or suboptimal USB cable quality while providing absolutely no useful gain in our application, whereas FT2232D is inherently safer in this regard by not having that USB high speed capability in the first place. FT2232D is a direct drop-in for the earlier FT2232C and FT2232L chips; FT2232D is a currently active part available from Digi-Key whereas its predecessors are surplus-only parts. FT2232C/D devices only support MPSSE on Channel A, hence our FreeCalypso UART+JTAG adapter will follow the general canon for such adapters in that JTAG and test reset will be on Channel A, whereas Channel B will be used for the RVTMUX UART. There will be a 93C46 EEPROM connected to the FT2232D chip. This EEPROM is needed so that we can give our adapter a custom USB ID (out of the range of USB IDs allocated by FTDI to Falconia Partners LLC); this custom USB ID is needed for several reasons: * We don't want the ftdi_sio driver in the Linux kernel to create two ttyUSBx devices for both FT2232D channels only to have the first of the pair disappear when a custom libftdi-based program is run to make use of JTAG and/or reset functions on Channel A - instead we would like to have this driver create only one ttyUSBx device for the UART on Channel B. There already exist several other UART+JTAG adapters whose creators and users had the same need, and the ftdi_sio driver in Linux supports them. The existing adapters of this kind are identified by custom USB IDs, and once our own adapter advances past the vaporware phase, we'll be submitting a one-line patch to the Linux kernel driver to add our custom USB ID to the list. * We will have a custom libftdi-based program for sending nTESTRESET to the FreeCalypso GSM device target through our adapter; this program will have an easier time locating our USB device among other potential FTDI-based devices if we use a custom USB ID. * When the time comes to configure OpenOCD to do JTAG through our adapter, having a custom USB ID will similarly help prevent erroneous binding to other FTDI-based devices that may be present. 2.2. Buffering logic for JTAG One significant design blemish of the otherwise quite versatile FT2232D is that "bit" modes like MPSSE cannot be configured in the EEPROM, instead they can only be entered dynamically on software command from the host. As the result, an FT2232D channel that is meant to be used for, say, JTAG on a given board will still operate in its default UART mode when USB power is first applied, and will remain in this state indefinitely long, until the user runs a program on the host that issues a software command to enter the "bit" mode - which may never happen. If an FT2232D channel is wired for JTAG but the chip operates in its default UART mode, the following problems will occur if the signals are wired directly without additional buffering logic: * The ADBUS0 line which becomes TCK in JTAG mode is TxD in UART mode, and will thus drive a high level on power-up - even though the quiescent state on TCK should be low. * JTAG TDO line (output from the target) needs to be connected to ADBUS2 - this signal becomes an input in MPSSE mode - but in the power-up default UART mode ADBUS2 is an output. Thus this default output can end up fighting with the target's TDO output, potentially damaging the target, the adapter or both. (The other two JTAG signals - TDI and TMS driven from ADBUS1 and ADBUS3 - are less of a problem because in the power-up default UART mode these FT2232D pins are inputs with weak internal pull-ups on them.) Our solution to this problem is to insert 3-state buffers (unidirectional in the JTAG signal direction) into all 4 JTAG lines. We shall use 3-state buffers with active-low enables, and the two enable lines (one for the TCK, TDI and TMS outputs from the adapter, the other for the TDO input) will come from FT2232D pins ADBUS5 and ADBUS6. In the MPSSE mode used for JTAG these pins become GPIOs and will need to be configured as outputs driving low in order to enable JTAG, but in the power-up default UART mode they are inputs with internal pull-ups, and we will have additional external pull-ups for safety. The effects will be as follows: * As long as the FT2232D channel is in UART mode, the 3-state buffers can never be enabled. All JTAG outputs from the adapter will be tristated (i.e., the same as if the adapter weren't there, presenting the target with its normal sans-JTAG state), there will be no fighting on ADBUS2, and the UART will sense all of its inputs as inactive high. * As the MPSSE mode is entered on software command, the initial pin direction mask byte should be 0x01, keeping ADBUS0 as an output, but then an MPSSE GPIO command should be given, enabling the other outputs along with sensible initial values. * ADBUS6 should be driven low to enable the TDO receiving buffer (it will have a weak pull-up on the buffer's input in order to not float when there is no target connected) right after ADBUS2 is switched to being an input, but ADBUS5 can be driven low or high at any time afterward to enable or disable the JTAG outputs. 2.3. Sideband signals alongside JTAG 2.3.1. Iota nTESTRESET driver The test reset line in the Calypso+Iota solution (nTESTRESET) is handled by the VRPC block in the Iota ABB which is essentially a PMIC. It is always pulled up inside the GSM device to a non-logic power rail, and this circuit works even when the mobile is in the switched-off state with all of the main voltage regulators for regular logic turned off. The raw nTESTRESET line is not meant to ever be driven by any kind of active push-pull logic driver; instead it is meant to be shorted to GND to trigger the reset, through either a pushbutton switch or an OC/OD driver. Back when TI made their x-Sample and Leonardo development boards, they apparently preferred to drive their JTAG+reset test interface (14-pin header in TI's JTAG pinout) with whatever generic (non-Calypso-specific) JTAG adapter they already had at the time, and as their 14-pin JTAG interface was defined, pin 2 (reset) was defined to be TRST with an active push-pull driver in the JTAG host adapter (or "emulator" as they call it). These x-Sample and Leonardo boards have a little on-board circuit between this connector pin 2 and the actual nTESTRESET; this circuit consists of two transistors and has the effect of protecting the internal nTESTRESET line from whatever the external driver may be doing: if the external adapter drives a logic low, the transistor circuit pulls nTESTRESET low via what is effectively an OC driver, otherwise the JTAG block presents a Hi-Z state to the nTESTRESET line. This circuit has been copied from Leonardo schematics on our own FCDEV3B, but the current plan is to not include it on the handset board, instead bringing out nTESTRESET in its native form on the FFC interface like the Pirelli DP-L10 board appears to do. Our FreeCalypso UART+JTAG adapter will drive this nTESTRESET pin with an open drain driver. This driving arrangement is compatible with both approaches: either direct nTESTRESET connection or the transistor circuit on FCDEV3B and on TI's boards. It does, however, make our adapter specific to Calypso+Iota GSM devices: more generic ARM processors and DSPs will often have more standard TRST and/or SRST signals instead, possibly needing active push-pull drivers. To protect the reset line from FTDI's UART-default bogosity, the input to the non-inverting open drain driver will come from ADBUS7, which is an input in the FT2232D's power-up default UART mode. Like ADBUS5 and ADBUS6 controls for the 3-state buffers for JTAG, this ADBUS7 line will have an additional external pull-up for safety, thus the reset can never be triggered accidentally while the FT2232D channel is in UART mode - the only way to trigger the test reset will be to first put the channel into the MPSSE+GPIO mode, then make ADBUS7 an output driving low. 2.3.2. Calypso nEMU0 and nEMU1 pins The Calypso chip has two JTAG-sideband pins called nEMU0 and nEMU1. They form some kind of debug/development interface which is not needed in normal product operation, and all Calypso-based GSM phone and modem product boards known to us leave them unconnected - even those product boards on which the regular JTAG pins are brought out (Pirelli DP-L10 and some Mot C1xx variants). TI's Leonardo schematics leave them unconnected as well, but their more complete x-Sample boards have them brought out to the 14-pin JTAG connector. Our FCDEV3B has them brought out as well. The problem with these nEMU0 and nEMU1 pins is that they are undocumented: the docs we have only say that they are bidirectional signals with pull-ups, and nothing else. We have on-board pull-ups on these two lines on our FCDEV3B (copied from TI's E-Sample board) strengthening the Calypso chip's supposed internal pull-ups, but we don't know what will happen if either or both pins are driven low externally (at boot or any other time), nor do we know if the Calypso chip itself ever drives or pulses them low as outputs. Common sense suggests that one of their likely functions is probably to hold the ARM7 core in the debug halt state directly out of reset, and possibly disable the watchdog timer which is otherwise enabled and ticking at this time - but we don't know any of the details. Because we don't know exactly how these nEMU0 and nEMU1 pins work, the only sense in which we can support them is to provide a way to use our FreeCalypso UART+JTAG adapter as a reverse engineering tool, experimentally playing with these nEMU[1:0] pins on an FCDEV3B. We are going to make the following simple provision to facilitate such experimentation: we are going to connect FT2232D pins ACBUS2 and ACBUS3 to pins 13 and 14 on the 14-pin JTAG header, which are the pins for nEMU0 and nEMU1. Unlike all other signals, this one will be a direct connection without any buffering. ACBUS2 and ACBUS3 function as open drain LED drivers in the power-up default UART mode, and these pins have been chosen on the reasoning that they are expected to stay non-driving as long as no one actually opens Channel A as a UART and tries to send something through it. The following important additional considerations apply: * These nEMU0 and nEMU1 signals are NOT included in the FFC interface defined by Foxconn/Pirelli which we are copying for our FreeCalypso handset boards. The positive implication is that the development interface for these FC handset boards will not be adversely affected by the potentially dangerous unbuffered connection to FT2232D pins; the negative implication is that if we ever do learn how to use these nEMU[1:0] pins to do whatever they can do, that ability won't be available on the handset boards. However, the latter loss is deemed to be acceptable: the most plausible function of these nEMU[1:0] pins is to enter JTAG debug state directly out of reset, and we don't need this ability when we have the internal boot ROM enabled via nIBOOT: we can interrupt and divert the boot process serially, and then enter the debug state through the regular JTAG scan chain. * Anyone using the 14-pin JTAG header interface to connect to a target such as FCDEV3B that does have nEMU0 and nEMU1 signals on pins 13 and 14 still has the freedom to connect or not connect these signals as desired. With our current FCDEV3B certain mechanical constraints practically impose the requirement of making a custom cable in any case: the spacing between headers on the FCDEV3B is too tight for standard ribbon cables terminated with IDC connectors (there is no room for the bulky sides of those IDC connectors), hence one needs to crimp female terminals onto individual wires and insert them into a crimp housing instead. In light of these considerations, you should only connect pins 13 and 14 between our adapter and your target if you are specifically interested in experimenting with driving or sensing Calypso's nEMU0 and nEMU1 signals, otherwise leave them unconnected. * Our entire "support" for these nEMU[1:0] pins will consist of two PCB traces connecting FT2232D's ACBUS2 and ACBUS3 pins to two pins on the 14-pin JTAG header. This arrangement, which could be considered quite risky under different circumstances, does absolutely nothing and cannot cause any harm if those two header pins are NOT subsequently connected to an actual Calypso target. 2.4. FT2232D I/O pin summary Channel A pins will be assigned and connected as follows: ADBUS0: JTAG TCK (fixed by FTDI) ADBUS1: JTAG TDI (fixed by FTDI) ADBUS2: JTAG TDO (fixed by FTDI) ADBUS3: JTAG TMS (fixed by FTDI) ADBUS4: unused and unconnected ADBUS5: active-low output enable control for JTAG outputs ADBUS6: active-low output enable control for TDO receiving buffer ADBUS7: active-low nTESTRESET control ACBUS0: unused and unconnected ACBUS1: unused and unconnected ACBUS2: wired to JTAG header pin 13 (nEMU0) ACBUS3: wired to JTAG header pin 14 (nEMU1) The 3 pins that are unused and unconnected (ADBUS4, ACBUS0 and ACBUS1) can be configured as either inputs with internal pull-ups or outputs. For the remaining pins which do have assigned functions, the following software init sequence should be adhered to: * As the MPSSE mode is entered on software command, the initial pin direction mask byte should be 0x01. The critical points are to set ADBUS0 as an output at this point so it never glitches through a non-driving state (it is TxD in the power-up default UART mode), make ADBUS2 an input as it will need to be once TDO is enabled, and set ADBUS5-7 as inputs. ADBUS5-7 need to be inputs at this stage (the connected logic will sense the inactive high level from pull-up resistors) because the initial output value for initialized-as-output pins is not defined. * MPSSE Set Data Bits High Byte (0x82) command should be given to set ACBUS2 and ACBUS3 as inputs, leaving nEMU[0:1] pins undisturbed until and unless you are playing with them. * MPSSE Set Data Bits Low Byte (0x80) command should be given to make ADBUS0 (TCK) an output driving 0, make ADBUS1 (TDI) an output driving 1, keep ADBUS2 as an input from the MPSSE mode entry step, make ADBUS3 (TMS) an output driving 1, and make ADBUS6 (TDO receiving buffer control) an output driving 0. ADBUS5 (JTAG output buffer control) and ADBUS7 (nTESTRESET driver) should be configured as outputs at this point, but their driving values will depend on the application. Channel B will be used as a data-leads-only UART with standard wiring requiring no software intervention: BDBUS0: TxD (UART output) BDBUS1: RxD (UART input) the rest: unused and unconnected 2.5. Logic voltage levels and buffering Many FT2232x-based JTAG adapters have level-translating buffers between FT2232x pins and the target interface in order to support targets with different logic voltage levels, usually from 3.3 V down to 1.8 V, or sometimes an even wider allowed range: for example, the Flyswatter2 adapter from Tin Can Tools supports target logic voltage levels from 1.6 to 5.0 V. In our case such voltage level shifting is not really needed: Calypso is 2.8 V native, but perfectly tolerant of 3.3 V inputs as well. The following approaches have been considered for our FreeCalypso UART+JTAG adapter: Approach 1: put a 3.3 V regulator on our board, run FT2232D I/O pins at 3.3 V, run the 3-state buffers for JTAG at 3.3 V as well, and connect the UART lines to FT2232D Channel B pins directly, without buffering. This approach relies on Calypso's inputs being tolerant of 3.3 V and Calypso's 2.8 V outputs producing voltage levels suitable for 3.3 V inputs. In practice this approach has already been used quite extensively in other contexts: we connect Calypso I/O to 3.3 V logic when we connect FCDEV3B UARTs to generic off-the-shelf FT2232x adapter boards, users of headset jack serial adapters for Motorola and Openmoko phones do likewise, Openmoko connected Calypso's 2.8 V UART to their 3.3 V application processor, and Foxconn/Pirelli appear to have done likewise with their built-in USB-serial interface based on a CP2102 chip with 3.3 V I/O. Approach 2: put both 3.3 V and 2.8 V regulators on our board, run FT2232D I/O pins at 3.3 V (the lowest I/O voltage officially supported by FT2232x chips), have the inputs from the Calypso target go directly to 3.3 V logic like with Approach 1, but run the 3-state buffers for JTAG outputs plus an always-enabled buffer for the UART output at 2.8 V. This approach makes the adapter's outputs 2.8 V proper, but at the cost of an extra on-board regulator. Approach 3: similar to Approach 2, but omit the on-board 2.8 V regulator and instead power the 2.8 V output buffers from the target voltage reference pin provided both on TI's 14-pin JTAG interface (used on development boards, both TI's and our own FCDEV3B) and on the FFC interface we are copying from Foxconn/Pirelli. Compared to Approach 2, this approach eliminates the extra on-board regulator, but would cause some power to be drawn from the target to power the output buffers. This approach would also create difficulties if a user wishes to use the generic header interface (as opposed to the highly specialized FFC interface), and there is no source from which the target reference voltage pin can be supplied. A compromise approach could be implemented by putting a 3-pin jumper header on our board, selecting the power to the output buffers between internal 3.3 V and the external target voltage reference pin, but having that jumper set to the internal 3.3 V supply would effectively bring us back to Approach 1. Approach 4: do what the "big guys" do in terms of voltage level translation: use special dual-supply translating buffers in both directions, supporting any target voltage level at least between 1.8 and 3.3 V or possibly wider. This approach would be appropriate for a more general-purpose JTAG adapter that needs to work with, say, 1.8 V targets, but given that our adapter is specific to the Calypso which has 2.8V-native, 3.3V-tolerant I/O, the extra complexity of full-blown voltage level translation is not really justifiable. Approaches 3 and 4 are excessively complex and cumbersome, and cannot be justified in our Calypso-specific application. The practical choice is thus between approaches 1 and 2. My (Mother Mychaela's) initial leaning was toward Approach 1, but upon further reflection I swayed over to Approach 2. The cost of the additional on-board 2.8 V regulator in terms of PCB real estate and layout complexity is not too great, and given that our adapter is very specifically for the Calypso and no other targets, it makes more sense to put out Calypso's native voltage levels, rather than merely compatible ones. Approach 2 will be used on our FreeCalypso UART+JTAG adapter, with the following additional nuances: * A 74LVC125A output buffer (4 individual buffers in one package) powered from the 2.8 V regulator will be used for the 4 logic outputs from our adapter: JTAG outputs TCK, TDI and TMS, and the single UART output. The output enables for the JTAG outputs will come from ADBUS5, whereas the UART output will be always enabled. * Another similar buffer, but powered from the 3.3 V regulator will be used for the two logic signals going the other way: JTAG TDO and the UART input. The buffer for TDO will be enabled by ADBUS6, the UART input will be always enabled. There will be a pull-up resistor to local 2.8 V on the input (target interface) side of each buffer. The buffer for TDO is needed for 3-state control, but an identical buffer will also be used for the UART input for the sake of symmetry, and to present the target with a pull-up to 2.8 V rather than FT2232D's internal pull-up to 3.3 V. * All pull-ups on the interface between FT2232D pins and the just-described buffers will be to 3.3 V. * A dedicated 3.3 V regulator will be used, instead of trying to use the feeble one built into the FT2232D, as the datasheet-stated limit of 5 mA seems like too little margin. * The only interface on which the target would ever see 3.3 V rather than 2.8 V will be the purely experimental provision for Calypso nEMU[1:0] described in section 2.3.2, to be used only by those who are specifically interested in that line of experimentation, and not in any other use cases. It makes no sense to attempt voltage level-translating buffering for these signals when we don't even know if they are really inputs or outputs, and under what conditions. The target voltage reference pins on the TI-style 14-pin JTAG header connector and on the Foxconn/Pirelli-style FFC connector will remain unused and unconnected. One could make an argument that not using the target-provided I/O voltage reference is wrong, but the issue needs to be seen in context. TI's 14-pin JTAG interface was designed for use in a wide range of applications, covering I/O voltages at least between 1.8 and 3.3 V, and TI's XDS JTAG adapters support this wide range of I/O voltages just like the ones made by community vendors like Amontec and Tin Can Tools. In the case of Foxconn and their Pirelli DP-L10 design, we can never know for certain, but it is highly plausible that they weren't making a custom FT2232x-based JTAG adapter of their own like we are doing, and instead had a passive adapter that connected their FFC interface to some existing TI XDS JTAG adapter, likely via that very same 14-pin interface. In that case the existing TI XDS JTAG adapter they were using needed a target voltage reference pin, and so they included one in their custom FFC interface. But our circumstances are different: we are making a custom UART+JTAG adapter for reasons of our own, and because our custom adapter is very specific to the Calypso, having our own on-board 2.8 V regulator is more robust than depending on an I/O buffer supply from the target. 2.6. Target connection interfaces 2.6.1. Generic header interface Our FreeCalypso UART+JTAG adapter will feature two header connectors: a 14-pin header in TI's pinout for JTAG, nEMU[1:0] and nTESTRESET, and a separate 3-pin header for the UART. This header interface option will make it possible to use our adapter with the FCDEV3B, with TI's D-Sample board (JTAG+company 14-pin interface only) and even with hacked-up C1xx phones with little wires soldered to JTAG test pads. As explained in section 2.3.2, always give explicit thought as to whether pins 13 and 14 (nEMU0 and nEMU1) should be connected or not in your application. The UART on FT2232D Channel B will be completely independent of JTAG and other Channel A functions, and can be used as a completely generic data-leads-only asynchronous serial interface at 2.8 V. 2.6.2. FFC interface Our upcoming FreeCalypso handset boards will need to use an FFC interface for development functions. At the very minimum this interface needs to connect the Calypso's IrDA UART carrying RVTMUX, and do it in such a way that this serial interface can be connected without applying a "charger present" condition to the VRPC block in the Iota ABB - hence the need for an interface outside of the handset's built-in USB-serial port. Furthermore, if we copy the FFC interface from Foxconn's Pirelli DP-L10 design instead of inventing our own, we get not only a UART channel, but also JTAG and nTESTRESET on the same interface. There is very little need for JTAG in FreeCalypso, but it is certainly a nice-to-have. Having the ability to drive nTESTRESET from the development host will also come very useful: once we implement proper handset on/off logic in the firmware, meaning that different switch-on causes will be treated like they should be in a real handset, switch-on from nTESTRESET will become the development and production boot mode. Our FFC interface is effectively defined by the unpopulated FFC connector footprint and its wiring found in Pirelli DP-L10 phones. It is a 12-pin FFC interface with 0.5 mm pitch, the unpopulated connector footprint on Pirelli's PCB has pin numbers marked on the silk screen, and the pins are assigned as follows: Pin Function ---------------- 1 V-IO rail 2 UART Rx (input to the target) 3 Iota nTESTRESET 4 JTAG TDI 5 JTAG TMS 6 JTAG TCK 7 UART Tx (output from the target) 8 JTAG TDO 9 unused 10 GND 11 unused 12 unused At one time we had a plan to add Calypso nEMU[1:0] signals to this interface by putting them on the last two unused pins, but this addition has been rejected for the time being: because we have no documentation for what these nEMU[1:0] pins do and all we can do with them are reverse engineering experiments, these signals should be kept out of handset products and limited to development boards like FCDEV3B for the time being. There is, however, one critical aspect of this FFC interface which cannot be recovered from the Pirelli DP-L10 artifacts and instead has to be defined anew: the question of top vs. bottom orientation. Our decision process in this regard begins with the availability of FFC jumpers, i.e., the flat flexible piece that goes between the two boards. The FFC jumper version with same-side contacts is readily available from Digi-Key as very inexpensive single pieces, but the version with opposite-side contacts is only available with a prohibitely expensive MOQ. Having settled on the FFC jumper with same-side contacts, we are left with two options: have the contacts on both sides face upward, or have them face downward. The decision between the two is completely arbitrary and we have no way of knowing which way Foxconn had it back in their day, but we have to decide one way or the other starting with the design of this adapter board. The Mother's arbitrary decision is to have the contacts on both sides of the FFC jumper face upward, meaning that: * The FFC connector on the FreeCalypso UART+JTAG Adapter board will need to be the top-side contacts version. * If we are going to populate an FFC connector on a decased Pirelli motherboard in order to exercise our adapter against that pre-existing target, the top- side contacts version will need to be used. We'll need to do the same if we make our own handset board on which the FFC connector is on the side with the display and the main keypad buttons. * If we make our own handset board on which the FFC connector is on the bottom side of the motherboard (the side opposite the display), which is the current plan, the connector will need to be the bottom-side contacts version. Because pin 1 is on the left on the existing target board with the connector on the top side (Pirelli DP-L10) and we are using the same-side jumper version that flips the left/right orientation, pin 1 will need to be on the right in the connector footprint definition on the adapter board.