NOTE: OUTDATED ARTICLE!!!

The following article was written in 2018-10; it is now 2019-03 and we have got
MCSI working - see the new Calypso-digital-voice article.  The original article
below is only for history preservation.

Original article with outdated info follows
===========================================

The Calypso chip provides a little-used auxiliary synchronous serial interface
called MCSI.  It is an auxiliary interface to the DSP part of the Calypso
(controlled solely by the DSP and not directly accessible to the ARM part); it
is not clear what other uses TI may have had in mind for this interface, but
one advertised feature of TI's TCS211 chipset+firmware solution is Bluetooth
support in the form of using MCSI as a digital voice channel to be connected to
TI's Bluetooth Island chip.  In FreeCalypso we are not interested in Bluetooth
per se, but we are interested in getting a digital voice channel out of our
modem for GSM voice calls in order to compete with the mainstream proprietary
GSM modem modules which do provide such digital voice channels.

Our current development board (FCDEV3B) has MCSI brought out on a header for
experimentation, and we had high hopes that we could use TI's so-called
"Bluetooth headset" mode (the mode in which the voice path is connected between
GSM and "Bluetooth" on MCSI) to get a usable digital voice channel out of our
modem.  However, experiments have revealed the following:

1) The good part: when our TCS211-based fw is given a command to switch into
the Bluetooth headset mode (auw 0 2 through fc-tmsh or our own added AT@VPATH=2
command), MCSI comes alive: a 520 kHz bit clock appears on MCSI_CLK and an 8 kHz
frame sync signal appears on MCSI_FSYNCH.

2) The bad part: as soon as I dial a voice call after having enabled the
Bluetooth headset mode as above, the MCSI clock and frame sync signals
*disappear* at some point in the voice call setup process!  I can make them
reappear by switching to AT@VPATH=0 (the regular GSM-to-ABB voice routing mode)
and then back to AT@VPATH=2 (merely repeating AT@VPATH=2 or auw 0 2 is not
sufficient, one has to switch to another mode and then back to Bluetooth
headset), and then the MCSI clock & frame sync disappearance no longer happens
on subsequent calls - they stay on.  I can similarly make these MCSI clock &
frame sync signals come on and stay on if I issue the initial AT@VPATH=2 command
*after* the first voice call has been connected - but it is not clear at all
exactly which step in the call setup process one would need to wait for.

To me (Mother Mychaela) it would make sense for the DSP to keep MCSI clocks off
during idle and only turn them on during active voice calls (doing so would
avoid erratic clock output as the modem goes into and out of deep sleep during
idle), but the behaviour we are seeing seems like TI tried to do what I just
said, but got the logic reversed.

This erratic behaviour with MCSI clocks getting turned off when they should be
getting turned on makes this interface unusable beyond lab experimentation in
my maternal opinion - dunno about others, but I would not be able to market a
commercial FreeCalypso modem product with a digital voice channel via MCSI if
the behaviour of the interface is clearly buggy and requires hacky workarounds
on the part of the end user.  For this reason no further work has been done to
see if the MCSI_TXD line actually puts out sensible voice downlink bits and if
the MCSI_RXD line accepts voice uplink bits in a sensible format when an active
voice call is in progress and the clocks are on.

As I see it, there are 3 ways we can solve this digital voice channel problem:

1) The most ideal option would be to convince TI to dig up and release the
source for the Calypso DSP ROM: getting that source and being able to study it
would solve all of our problems at the root.  We would then understand exactly
what the DSP does with regard to MCSI, and either change its behaviour to a
more desirable one by way of a DSP patch, or adapt our ARM-side fw or even the
external control interface definition to what will then be fully known DSP
behaviour.

2) If TI no longer have the source for the Calypso DSP ROM or are unable to
find it because of the length of time that has passed (about 15 y), or if they
have it but we are not able to convince them to release it, we could reverse-
engineer this ROM by disassembling the ROM image that has been read out.
However, reversing this ROM thoroughly enough to serve as a replacement for the
lost original source would be an extremely costly undertaking: if I were to do
it, I would need to be given a full year to work on it on a full-time basis, at
the cost of about 150 kUSD, and I find it doubtful that any other professional
reverser of sufficient qualification level would do it for less.  Needless to
say, it is highly unlikely that anyone in our ultra-marginalized FreeCalypso
community can spare 150 kUSD, and if someone does have that kind of money to
spend toward the liberation of the Calypso DSP, the sensible course of action
would be to first offer that money to TI in exchange for the DSP ROM source
before giving it to a reverser.

3) If someone has an actual (as opposed to hypothetical) money-backed business
need for a Calypso-based modem with a digital voice interface, the fastest and
cheapest solution would be to forego MCSI and tap into VSP instead, as described
in the FCDEV3B-repackaging article in the section titled "Tapping VSP for the
digital voice interface".  This option would require designing and building a
new PCB, which would probably cost some 10 to 15 kUSD, but it is far less than
the 150 kUSD that would be needed for DSP ROM RE, and the timeline would be
much shorter too.  Unlike MCSI, VSP is used in the regular voice path going
through the ABB, hence it is *known* to be good with no possibility of nasty
surprises.