FreeCalypso > hg > freecalypso-docs
view MCSI-apparent-bug @ 12:9baf6215285b
Calypso-digital-voice: typo fix
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Thu, 28 Mar 2019 16:33:31 +0000 |
parents | 43829da82312 |
children | 8a3fd530a647 |
line wrap: on
line source
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.