FreeCalypso > hg > freecalypso-docs

comparison MCSI-apparent-bug @ 7:43829da82312

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
MCSI-apparent-bug article written
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 11 Oct 2018 18:26:32 +0000
parents
children 8a3fd530a647
comparison
equal deleted inserted replaced
6:700d6cff63bb 7:43829da82312
1 The Calypso chip provides a little-used auxiliary synchronous serial interface
2 called MCSI. It is an auxiliary interface to the DSP part of the Calypso
3 (controlled solely by the DSP and not directly accessible to the ARM part); it
4 is not clear what other uses TI may have had in mind for this interface, but
5 one advertised feature of TI's TCS211 chipset+firmware solution is Bluetooth
6 support in the form of using MCSI as a digital voice channel to be connected to
7 TI's Bluetooth Island chip. In FreeCalypso we are not interested in Bluetooth
8 per se, but we are interested in getting a digital voice channel out of our
9 modem for GSM voice calls in order to compete with the mainstream proprietary
10 GSM modem modules which do provide such digital voice channels.
11
12 Our current development board (FCDEV3B) has MCSI brought out on a header for
13 experimentation, and we had high hopes that we could use TI's so-called
14 "Bluetooth headset" mode (the mode in which the voice path is connected between
15 GSM and "Bluetooth" on MCSI) to get a usable digital voice channel out of our
16 modem. However, experiments have revealed the following:
17
18 1) The good part: when our TCS211-based fw is given a command to switch into
19 the Bluetooth headset mode (auw 0 2 through fc-tmsh or our own added AT@VPATH=2
20 command), MCSI comes alive: a 520 kHz bit clock appears on MCSI_CLK and an 8 kHz
21 frame sync signal appears on MCSI_FSYNCH.
22
23 2) The bad part: as soon as I dial a voice call after having enabled the
24 Bluetooth headset mode as above, the MCSI clock and frame sync signals
25 *disappear* at some point in the voice call setup process! I can make them
26 reappear by switching to AT@VPATH=0 (the regular GSM-to-ABB voice routing mode)
27 and then back to AT@VPATH=2 (merely repeating AT@VPATH=2 or auw 0 2 is not
28 sufficient, one has to switch to another mode and then back to Bluetooth
29 headset), and then the MCSI clock & frame sync disappearance no longer happens
30 on subsequent calls - they stay on. I can similarly make these MCSI clock &
31 frame sync signals come on and stay on if I issue the initial AT@VPATH=2 command
32 *after* the first voice call has been connected - but it is not clear at all
33 exactly which step in the call setup process one would need to wait for.
34
35 To me (Mother Mychaela) it would make sense for the DSP to keep MCSI clocks off
36 during idle and only turn them on during active voice calls (doing so would
37 avoid erratic clock output as the modem goes into and out of deep sleep during
38 idle), but the behaviour we are seeing seems like TI tried to do what I just
39 said, but got the logic reversed.
40
41 This erratic behaviour with MCSI clocks getting turned off when they should be
42 getting turned on makes this interface unusable beyond lab experimentation in
43 my maternal opinion - dunno about others, but I would not be able to market a
44 commercial FreeCalypso modem product with a digital voice channel via MCSI if
45 the behaviour of the interface is clearly buggy and requires hacky workarounds
46 on the part of the end user. For this reason no further work has been done to
47 see if the MCSI_TXD line actually puts out sensible voice downlink bits and if
48 the MCSI_RXD line accepts voice uplink bits in a sensible format when an active
49 voice call is in progress and the clocks are on.
50
51 As I see it, there are 3 ways we can solve this digital voice channel problem:
52
53 1) The most ideal option would be to convince TI to dig up and release the
54 source for the Calypso DSP ROM: getting that source and being able to study it
55 would solve all of our problems at the root. We would then understand exactly
56 what the DSP does with regard to MCSI, and either change its behaviour to a
57 more desirable one by way of a DSP patch, or adapt our ARM-side fw or even the
58 external control interface definition to what will then be fully known DSP
59 behaviour.
60
61 2) If TI no longer have the source for the Calypso DSP ROM or are unable to
62 find it because of the length of time that has passed (about 15 y), or if they
63 have it but we are not able to convince them to release it, we could reverse-
64 engineer this ROM by disassembling the ROM image that has been read out.
65 However, reversing this ROM thoroughly enough to serve as a replacement for the
66 lost original source would be an extremely costly undertaking: if I were to do
67 it, I would need to be given a full year to work on it on a full-time basis, at
68 the cost of about 150 kUSD, and I find it doubtful that any other professional
69 reverser of sufficient qualification level would do it for less. Needless to
70 say, it is highly unlikely that anyone in our ultra-marginalized FreeCalypso
71 community can spare 150 kUSD, and if someone does have that kind of money to
72 spend toward the liberation of the Calypso DSP, the sensible course of action
73 would be to first offer that money to TI in exchange for the DSP ROM source
74 before giving it to a reverser.
75
76 3) If someone has an actual (as opposed to hypothetical) money-backed business
77 need for a Calypso-based modem with a digital voice interface, the fastest and
78 cheapest solution would be to forego MCSI and tap into VSP instead, as described
79 in the FCDEV3B-repackaging article in the section titled "Tapping VSP for the
80 digital voice interface". This option would require designing and building a
81 new PCB, which would probably cost some 10 to 15 kUSD, but it is far less than
82 the 150 kUSD that would be needed for DSP ROM RE, and the timeline would be
83 much shorter too. Unlike MCSI, VSP is used in the regular voice path going
84 through the ABB, hence it is *known* to be good with no possibility of nasty
85 surprises.