# HG changeset patch # User Mychaela Falconia # Date 1571790396 0 # Node ID 9f9d2996c1bac62ffd30223f4b9f0965657de5e8 # Parent 69ee60206c531cf62035cbd468bd9c4750134d3f MCSI-apparent-bug outdated article removed: see Calypso-digital-voice for up-to-date replacement diff -r 69ee60206c53 -r 9f9d2996c1ba MCSI-apparent-bug --- a/MCSI-apparent-bug Wed Oct 23 00:11:37 2019 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,94 +0,0 @@ -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.