FreeCalypso > hg > freecalypso-docs

comparison FCDEV3B-repackaging @ 2:020df28341d0

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
FCDEV3B-repackaging article written
author Mychaela Falconia <falcon@freecalypso.org>
date Wed, 10 Oct 2018 07:28:15 +0000
parents
children 4f873ec004f6
comparison
equal deleted inserted replaced
1:068a27407d75 2:020df28341d0
1 Repackaging FreeCalypso modem into different physical form factors
2 ==================================================================
3
4 As of this writing, our FreeCalypso Triband Modem Solution has reached the
5 status of a finished product: it is no longer experimental or developmental,
6 it is now fully fit for operational use on live public GSM networks in end user
7 applications that need a standards-compliant GSM+GPRS modem. However, at the
8 present moment it is only available in the physical form factor of a development
9 board (FCDEV3B) that was originally designed to serve as a software/firmware
10 development platform, and as such it is not ideally suited for use as an end
11 product. For end use applications it would be highly desirable to take our
12 proven FC Triband Modem Solution (FC-TMS) as realized on the FCDEV3B and
13 repackage it into other physical form factors. This repackaging can be done
14 in two ways:
15
16 Approach 1 (strongly preferred): the party who desires to have our FC-TMS in a
17 particular form factor gets in touch with FreeCalypso Central, engages in a
18 discussion with us to arrive at the new form factor to be implemented (it needs
19 to satisfy your requirements and be feasible for us to implement), then funds
20 the cost of PCB layout labor to turn the new form factor modem into reality.
21 More specifically, we would do the design at the schematics+BOM level while the
22 the PCB layout step would have to be outsourced at cost.
23
24 Approach 2 (NOT preferred, but can sometimes be agreed to in limited cases):
25 someone else does the repackaging work under their own control.
26
27 In the case of Approach 1 the new modem product will always be guaranteed to
28 work flawlessly and be fully compatible with our FreeCalypso sw and fw
29 architecture because in this case the hardware design is personally supervised
30 by the Mother of FreeCalypso and must receive her approval prior to being
31 released to layout and then to fabrication. In the case of Approach 2 this
32 assurance is lacking. This document provides some technical guidelines that
33 MUST be followed in order for a new modem hw product to stand a chance at being
34 compatible with FreeCalypso; anyone who follows Approach 2 against our
35 recommendation but still wishes to have a chance at receiving support from us
36 MUST follow these design guidelines.
37
38 LEGAL NOTICE: Following these technical guidelines does NOT by itself grant you
39 a license to use our FreeCalypso trademark on your hardware products; this
40 trademark is personally owned by Mychaela N. Falconia and only she has the
41 authority to license its use at her sole discretion. Similarly our agreement
42 with GSMA does NOT allow us to sublet any part of our IMEI number range to any
43 other parties; any IMEI number ranges that may be allocated by GSMA to
44 FreeCalypso products may ONLY be used for those products that are physically
45 produced by Falconia Partners LLC from start to finish and not any others.
46
47 Basic technical guidelines
48 ==========================
49
50 The purpose of these guidelines is to make it possible for the same firmware
51 build configuration to support both our existing FCDEV3B and various
52 repackagings of the underlying core modem solution (FC-TMS), i.e., to have the
53 same official FC Magnetite firmware builds for target fcdev3b run not only on
54 the original development board, but on all physical repackagings of the same
55 core modem solution. To make such firmware reuse possible, the following
56 hardware design constraints MUST be followed:
57
58 * The flash+RAM chip must be the same Spansion S71PL129NC0HFW4B as used on our
59 FCDEV3B, and it must be wired the same way: first flash chip select on Calypso
60 nCS0, RAM on nCS1, second flash chip select on nCS2. The flash reset line
61 needs to be wired the same way as on FCDEV3B V2, otherwise Calypso sleep modes
62 will be broken. We realize that this flash and RAM capacity (16 MiB and
63 8 MiB, respectively) is extreme overkill for typical modem applications
64 outside of development, but supporting multiple flash chip types would
65 introduce a configuration management burden which we are not willing to
66 take on.
67
68 * Calypso's unused DSR_MODEM/LPG pin was left unconnected in Openmoko's version
69 but on our FCDEV3B it is tied to GND on the board. Other boards seeking to
70 be FreeCalypso-compatible need to have this pin tied to GND as well because
71 our firmware leaves this pin in its default power-up config of DSR_MODEM input
72 and does not change it to LPG output - leaving it unconnected would cause it
73 to float.
74
75 * Our firmware configures Calypso GPIO 3 as an input; GPIOs 0-2 and those
76 multifunction pins which are unused and configured as GPIOs (TSPDI/IO4,
77 BCLKX/IO6, MCUEN1/IO8 and MCUEN2/IO13) are configured as outputs. Board
78 wiring must be compatible with these directions: those pins which our fw
79 drives as outputs can be simply left unconnected, while GPIO 3 needs to be
80 sensibly driven or tied off as explained below.
81
82 * If someone needs a modem that produces an Openmoko-style application processor
83 wakeup signal (asserted by the fw when the modem needs to send something to
84 the host but is blocked by CTS being held high), this signal should be
85 connected to GPIO 0. Openmoko used GPIO 1 for this purpose, but in
86 FreeCalypso GPIO 1 is taken because we use it for the loudspeaker control
87 signal like on TI's D-Sample and Leonardo boards, hence we are moving the AP
88 wakeup signal to GPIO 0, to be implemented if and when anyone builds a modem
89 based on FC-TMS that needs to be provide such a signal.
90
91 * If your product includes a loudspeaker amplifier like on our FCDEV3B, connect
92 its on/off control input to GPIO 1, otherwise leave our GPIO 1 output
93 unconnected.
94
95 * Our fw produces a DCD modem control output on GPIO 2; if you are connecting
96 the MODEM UART channel to an RS-232 port or to a USB-serial chip with a full
97 set of modem control signals, connect DCD to GPIO 2.
98
99 * Our fw treats GPIO 3 as a DTR modem control input following TI's C-Sample and
100 D-Sample boards. If your product has a real DTR signal coming from an RS-232
101 interface or from a USB-serial chip, connect it to GPIO 3, otherwise GPIO 3
102 needs to be pulled down to GND like on Leonardo and FCDEV3B.
103
104 * If you are connecting the MODEM UART channel to a full RS-232 port or to a
105 USB-serial chip with a full set of modem control signals, you should connect
106 DSR and RI to TSPDI/IO4 and MCUEN1/IO8, respectively. Right now our fw
107 drives IO4 low and IO8 high, corresponding to DSR asserted and RI negated
108 (normal quiescent state), and connecting the signals in this way allows the
109 possibility of extending the fw to drive them in some more intelligent manner.
110
111 * Both Calypso UARTs need to be wired in an accessible way so that our standard
112 FC Magnetite firmware can be used with the AT command interface on the MODEM
113 UART and RVTMUX on the IrDA UART.
114
115 * Our fw configures the MODEM UART with hardware flow control enabled; if your
116 applications lacks RTS/CTS signals, then Calypso's CTS_MODEM signal needs to
117 be pulled down to GND so it is seen as asserted.
118
119 * Our fw configures the 4 MCSI/GPIO pins as MCSI rather than GPIO. If your
120 board does not use MCSI because you are tapping VSP instead or not using any
121 digital voice interface at all, then you should put pull-down resistors on
122 MCSI_RXD, MCSI_CLK and MCSI_FSYNCH, otherwise these signals will float.
123
124 Tapping VSP for the digital voice interface
125 ===========================================
126
127 The Calypso+Iota chipset includes an interface called VSP for Voice Serial Port;
128 per TI's design intent it is a strictly private interface between Calypso and
129 Iota chips, but it is possible to tap into this interface to get an external
130 digital voice channel. TI's official method for getting a digital voice channel
131 out of a Calypso modem is to use MCSI in their so-called "Bluetooth headset"
132 mode, however, our experiments on the FCDEV3B have revealed that this interface
133 does not work the way one would naively expect. Unless we can convince TI to
134 dig up and release the sources for the Calypso DSP ROM, which we obviously
135 cannot count on, we won't be able to use MCSI reliably until and unless we
136 undertake to fully reverse their DSP ROM code from disassembly, which would be
137 an extremely major and very costly undertaking. Because of this unfortunate
138 situation, the alternative way of tapping into VSP needs to be given
139 consideration.
140
141 Tapping into VSP is absolutely not possible on our current FCDEV3B, as the
142 signals in question are currently routed directly from one BGA to another and
143 do not come up to the surface at any accessible point. The same situation holds
144 on every other existing Calypso phone and modem known to us - after all, VSP was
145 meant to be a private chip-to-chip interface. Instead we are presenting the
146 idea of tapping VSP as a possibility for anyone who undertakes to repackage our
147 FC-TMS into some new form factor and desires a digital voice channel while at
148 it.
149
150 In TI's standard solution VSP clock and frame sync signals are generated by the
151 Iota ABB and are inputs to the Calypso DBB. Because they are inputs to the
152 Calypso, it may be tempting to disconnect them from the ABB and have them
153 originate from an external source instead - however, TI's DSP code in the ROM
154 was most certainly written with the assumption that these signals will only
155 ever be driven by their ABB and never by anyone else, hence having them come
156 from a source whose timing does not come from the Calypso can cause all kinds
157 of strangeness which we will never be able to debug properly because the DSP is
158 a mysterious black box. Therefore, my (Mother Mychaela's) stance is that if
159 you break the VSP connection between Calypso and Iota, then you are entirely on
160 your own - don't expect any help from me. Instead my idea is to tap into VSP
161 without breaking it, specifically:
162
163 * Keep the clock and frame sync connection between Calypso and Iota, with Iota
164 remaining the driver on these nets - but also bring these signals out
165 externally, so external logic can sync itself to this interface as well.
166
167 * Do likewise for the line that carries downlink voice from the DBB to the ABB:
168 let the ABB receive it and use it to drive the analogue earpiece output (which
169 would be unconnected in a digital voice application), but let external logic
170 receive it too.
171
172 * Break only the line that carries uplink voice from the ABB to the DBB: bring
173 the Iota output side on one external interface pin and the Calypso input side
174 on another external interface pin. Putting a jumper on these adjacent header
175 pins would restore TI's original configuration and allow uplink voice to come
176 from an analogue microphone connected to the ABB, and if a digital uplink
177 voice source is desired, remove the jumper and have an external source provide
178 the bits which would otherwise come from Iota's voice ADC.
179
180 The above approach would provide a usable digital voice interface that would be
181 completely transparent (invisible) to the Calypso DSP and even to the ARM-side
182 firmware, hence it should work without any nasty surprises.