FreeCalypso > hg > freecalypso-docs

comparison Calypso-digital-voice @ 10:17003ecbb9fc

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Calypso-digital-voice article written, documenting MCSI success
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 28 Mar 2019 08:04:00 +0000
parents
children 9baf6215285b
comparison
equal deleted inserted replaced
9:5de1f72ce941 10:17003ecbb9fc
1 Digital voice on FreeCalypso modems via MCSI
2 ============================================
3
4 The Calypso chip provides a little-used auxiliary synchronous serial interface
5 called MCSI. It is an auxiliary interface to the DSP part of the Calypso
6 (controlled solely by the DSP and not directly accessible to the ARM part); it
7 is not clear what other uses TI may have had in mind for this interface, but
8 one advertised feature of TI's TCS211 chipset+firmware solution is Bluetooth
9 support in the form of using MCSI as a digital voice channel to be connected to
10 TI's Bluetooth Island chip. In FreeCalypso we are not interested in Bluetooth
11 per se, but we are interested in getting a digital voice channel out of our
12 modem for GSM voice calls in order to compete with the mainstream proprietary
13 GSM modem modules which do provide such digital voice channels.
14
15 Our current development board (FCDEV3B) has MCSI brought out on a header for
16 experimentation, and as of 2019-03 we finally got this MCSI working as a proper
17 digital voice interface.
18
19 Hardware interface
20 ==================
21
22 MCSI consists of 4 hardware signals:
23
24 * MCSI_CLK is the bit clock output from the Calypso; in pure hardware terms
25 this signal is bidirectional, but unless you are going to develop your own
26 DSP code patches, its direction is determined by the DSP ROM code, which
27 configures MCSI_CLK as an output, i.e., the Calypso acts as the clock master.
28
29 * MCSI_FSYNCH is the frame sync output from the Calypso; it is the same deal as
30 with MCSI_CLK: bidirectional in pure hardware terms, but if you are not
31 changing the DSP code with your own custom patches, it is an output from the
32 Calypso.
33
34 * MCSI_RXD is the voice uplink bits input to the Calypso: the user's application
35 processor needs to feed voice uplink bits to this pin as timed by MCSI_CLK
36 and MCSI_FSYNCH.
37
38 * MCSI_TXD is the voice downlink output from the Calypso: as the vocoder in the
39 Calypso DSP decodes received downlink speech from GSM codecs into linear PCM,
40 this PCM voice downlink is put out on this MCSI_TXD pin, in synchrony with
41 MCSI_CLK and MCSI_FSYNCH.
42
43 The format in which digital voice samples are exchanged via MCSI between the
44 Calypso and the user's application processor is 16-bit linear PCM, 8000 samples
45 per second, thus requiring 128 kbps of bandwidth. The synchronous serial
46 interface details are as follows:
47
48 * When MCSI is enabled, the Calypso puts out a 520 kHz clock on MCSI_CLK,
49 produced by dividing the 13 MHz master clock by 25. This clock as put out by
50 the Calypso has a perfect 50% duty cycle.
51
52 * Given that a new pair of samples (uplink and downlink) needs to be transferred
53 once every 125 us (1/8000th of a second, for 8000 samples per second), this
54 520 kHz bit clock is further divided by 65 to produce an 8 kHz clock on
55 MCSI_FSYNCH, i.e., every 65 bits there is a frame synchronization pulse on
56 MCSI_FSYNCH. The width of this frame sync pulse is one full bit time, the
57 pulse is active high, and the MCSI_FSYNCH line stays low the rest of the time.
58
59 * Calypso outputs MCSI_FSYNCH and MCSI_TXD are updated on the rising edge of
60 MCSI_CLK and should be sampled on the falling edge of the same clock by the
61 user's application processor. The MCSI_RXD input is sampled on the falling
62 edge of MCSI_CLK by the Calypso, and should be updated on the rising edge of
63 the same clock by the user's application processor.
64
65 * Each voice sample (both uplink and downlink) is transferred from the most
66 significant bit to the least significant bit (MSB first), starting with the
67 clock cycle immediately following the frame sync cycle, i.e., the cycle in
68 which MCSI_FSYNCH is asserted by the Calypso.
69
70 * Given that each frame is 65 bits long (520 kHz bit clock divided by 8 kHz
71 frame rate) and that 16 bit slots out of every frame are used to transfer
72 voice sample bits, plus one bit slot for frame sync, it follows that 48 bit
73 slots out of every frame are dummies. The Calypso puts out 0 bits on MCSI_TXD
74 in all bit slots that don't carry voice sample bits.
75
76 A graphical depiction of what I just described verbally can be found on page
77 3074 of this TI OMAP document:
78
79 ftp://ftp.freecalypso.org/pub/ARM/OMAP/sprugn4r.pdf
80
81 Calypso MCSI corresponds to what this OMAP document calls "Mode 1", i.e.,
82 Figure 21-14 at the top of the page, NOT the other one below it.
83
84 Enabling and disabling MCSI for digital voice
85 =============================================
86
87 TI's DSP ROM code supports two modes of operation in which MCSI is activated,
88 called "Bluetooth cordless" and "Bluetooth headset". In the "BT cordless" mode
89 the voice path is connected between the chipset's native analog voice hw and
90 MCSI, with GSM out of the picture; in the "BT headset" mode the voice path is
91 connected between the GSM vocoder and MCSI, with the local analog voice hw out
92 of the picture. The latter "BT headset" mode is the only one which we currently
93 support in FreeCalypso; the "BT cordless" mode does not work properly as of this
94 writing - the step of enabling the Voice Band Codec block in the Iota ABB for
95 this mode is currently missing. Proper support for the "BT cordless" mode can
96 be added if a real need for it ever arises, but it would take some work, and
97 right now there is no business case for it.
98
99 In TI's TCS211 firmware architecture (see TCS211-fw-arch document) entry into
100 and exit from these "Bluetooth" MCSI voice routing modes is handled via the
101 RiViera Audio Service fw component, specifically its Audio Mode facility,
102 usually via the audio_full_access_write() API call. When asked to switch voice
103 routing modes, this RV Audio Service component sends an MMI_AUDIO_MODE_REQ
104 message to L1, the L1A component passes the request to L1S, and L1S finally
105 twiddles the magic control bits in the DSP API RAM.
106
107 In FreeCalypso we currently provide two ways for the end user to enter the
108 "BT headset" mode for digital access to GSM voice:
109
110 * The original way is the AT@VPATH=n command, which provides "raw" access to
111 the RV Audio Service's voice routing mode switch call. Setting AT@VPATH=2
112 enters the "BT headset" mode, AT@VPATH=0 returns to the normal "GSM only"
113 mode (MCSI disabled), and AT@VPATH=1 enters the currently not-working
114 "BT cordless" mode.
115
116 * The new way is the session-long AT@VSEL=n boolean setting. In the default
117 AT@VSEL=0 mode the firmware functions like before (MCSI disabled, voice calls
118 go to the analog voice hw), but if your application needs the digital voice
119 interface instead of analog, you can set AT@VSEL=1 once at the beginning of
120 your modem session. In this AT@VSEL=1 mode, whenever a GSM voice call is
121 connected (dialed or answered), the MCSI clocks are switched on (MCSI_CLK and
122 MCSI_FSYNCH outputs come to life) and the "BT headset" voice routing mode is
123 entered at the appropriate point in the call establishment process; when the
124 call disconnects (either side hangs up), MCSI is turned off. The new logic
125 internally performs the equivalent of AT@VPATH=2 and AT@VPATH=0 at appropriate
126 times.
127
128 Why does one need our new AT@VSEL=1 logic for dynamic switching into and out of
129 MCSI "BT headset" mode, why not simply set AT@VPATH=2 upfront and run with it?
130 Two reasons:
131
132 1) If MCSI is enabled continuously and not just when needed during voice calls,
133 the DSP never goes quiescent during idle periods, and the Calypso is not
134 allowed to enter deep sleep. Both of these factors are detrimental to proper
135 power management - the whole idea is that when a GSM modem is idle (not in a
136 call, but listening to paging and ready to accept incoming calls), most of
137 the hw needs to be powered down as much as possible, to reduce power
138 consumption to a minimum and prolong standby battery life.
139
140 2) There is a bug in the DSP code (present in the ROM and not corrected by the
141 patches we are using) that manifests if MCSI is already running when the very
142 first voice call after system boot is connected. Our AT@VSEL=1 mechanism
143 reliably avoids this DSP bug (ensured by the timing sequence of when we turn
144 on the vocoder and when we turn on MCSI), and it is my (Mother Mychaela's)
145 guess that TI probably missed this DSP bug because their own Bluetooth
146 handling code most likely worked very similarly to my AT@VSEL=1
147 implementation.
148
149 Thus the short story is that if you are using the digital voice interface via
150 MCSI, just set AT@VSEL=1 at the beginning of your modem session, and whatever
151 hardware you connect to MCSI needs to be OK with the clocks (MCSI_CLK and
152 MCSI_FSYNCH) appearing only during active voice calls, and being off at other
153 times.
154
155 It should also be noted that the new AT@VSEL=1 mechanism is implemented properly
156 only in our new hybrid firmwares, i.e., Magnetite hybrid and Selenite. The
157 legacy configs (l1reconst etc) using the blob version of G23M PS and ACI from
158 Openmoko (maintained only for regression testing and debugging purposes) also
159 implement the AT@VSEL command, but the AT@VSEL=1 mode will work somewhat
160 erratically in that version: the modem may enable MCSI at the wrong time, and
161 it will sometimes fail to turn it off at the end of a call. The implementation
162 of this functionality resides entirely in the "high-level audio driver" module
163 in ACI, this module is different between TCS2 and TCS3 versions of ACI, and
164 there is no justification for expending the effort to make the new feature work
165 in the old version of ACI: it is an entirely new feature added in FreeCalypso,
166 not present in any old Calypso modems, hybrid fw is the way forward in FC, thus
167 we only need to support new features in our hybrid firmwares.
168
169 The alternative approach of tapping VSP
170 =======================================
171
172 MCSI is not the only digital voice interface in the Calypso chipset: there is
173 also another interface called VSP (Voice Serial Port), which is a private
174 interface between Calypso and Iota chips. Because it was always intended to be
175 a private interface internal to the core chipset, not an external application
176 interface like MCSI, none of the standard Calypso-based phone or modem board
177 designs expose it in any accessible way - instead it goes from one BGA to the
178 other on inner PCB layers with zero accessibility for probing. Our FCDEV3B is
179 no exception in this regard, as our modem core is based on a commercial modem
180 design from a decade before our time.
181
182 Because it took us a very long time to get MCSI working as a practically usable
183 digital voice interface (the new AT@VSEL=1 mechanism is the key, without this
184 firmware piece NCSI is not practically usable), much thought has been given
185 earlier to the alternative idea of tapping into VSP. There are two
186 possibilities with that one:
187
188 1) Given that Calypso VSP is a clock slave (it expects the ABB chip to provide
189 the clock and frame sync signals), those who desire their digital voice i/f
190 to be a PCM slave (not a PCM master like TI's "BT headset" function over
191 MCSI) will likely be very tempted to disconnect Calypso VSP from the Iota
192 chip entirely and to connect it to their own application instead. However,
193 in the absence of source code for the DSP ROM this approach would be
194 incredibly risky (if the DSP is not too happy with the non-Calypso-sourced
195 timing you feed to the VSP, how are you going to debug it deep within the
196 DSP black box?), and I (Mother Mychaela) consider it so risky that if anyone
197 wants to do it, you will be entirely on your own - don't expect any help
198 from me.
199
200 2) A much safer approach would be to keep the VSP clock and frame sync
201 connections between Calypso and Iota chips, but also make them available
202 externally, i.e., have your application logic sync itself to these clocks.
203 Voice downlink could then be received just by passively tapping VSP lines,
204 and sending your own voice uplink via VSP would require cutting only the one
205 line that carries voice uplink bits from Iota to Calypso. It would then
206 effectively be just like MCSI (a PCM master to the user's application), but
207 without requiring any support in the firmware, instead being completely
208 invisible to the Calypso firmware and to the DSP.
209
210 However, because we don't have any board on which VSP signals are accessible to
211 probing, there are several unknowns with this interface:
212
213 * Is the VSP clock produced by the Iota chip 500 kHz (13 MHz master clock
214 divided by 26) or 520 kHz (same master clock divided by 25)? The available
215 Iota datasheet says 500 kHz, but if that is correct, how is the frame sync
216 handled? 500 kHz does not divide evenly by 8 kHz. Does Iota's clock + frame
217 sync output alternate between 62-bit and 63-bit frames, producing an 8 kHz
218 frame rate on average? Sounds messy and convoluted...
219
220 * It is not clear at all exactly when Iota's VSP clocks are started and stopped,
221 and whether the bit clock runs continuously during an active call (like
222 MCSI_CLK does), or if it is gated on only for those bit slots that carry
223 actual voice sample bits.
224
225 If we are going to produce a new FreeCalypso modem based on our current FCDEV3B,
226 but repackaged into some end use form factor, as things stand today (2019-03),
227 we are going to use MCSI rather than VSP for the digital voice interface. While
228 MCSI has definitely been a huge hassle and requires the user to issue one extra
229 setup command (AT@VSEL=1) at the beginning of each modem session, at least it
230 is now a known beast, and a known-working one. Committing to VSP in a
231 commercial product design without ever having seen these VSP signals on an
232 oscilloscope would be very irresponsible; if someone really wishes to go with
233 VSP instead of MCSI, the responsible approach would be to first design and build
234 another development board with VSP signals brought out for experimentation, and
235 only then possibly use it in a commercial product design after it becomes a
236 known beast.
237
238 From the standpoint of pure curiosity, I would be very interested in a
239 development board with VSP access, just to answer the above questions and fill
240 that gap in my Calypso knowledge. But switching to a more practical hat,
241 spending some 10 to 15 kUSD just to satisfy that curiosity would be very
242 difficult to justify - thus there is a very strong chance that VSP will never
243 be explored, Which is not really a problem at all, as for a practically usable
244 external digital voice channel we now have working MCSI.