--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/MCSI-apparent-bug	Thu Oct 11 18:26:32 2018 +0000
@@ -0,0 +1,85 @@
+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.