# HG changeset patch # User Mychaela Falconia # Date 1539282392 0 # Node ID 43829da8231240148523b710183467edf768398c # Parent 700d6cff63bbbf4804812b29939bf1fe95b15704 MCSI-apparent-bug article written diff -r 700d6cff63bb -r 43829da82312 MCSI-apparent-bug --- /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.