Hello FC community, As the long-timers here will know, I have a strong desire to have a working digital voice interface option on our FreeCalypso Modem Solution - without this capability, the modem solution feels incomplete to me. There are two ways to get a digital voice interface out of a Calypso modem: (1) TI's official way is to use MCSI, an auxiliary interface into the DSP, or (2) the alternative hacky way is to tap into the VSP interface between Calypso and Iota chips, which is officially a private chip-to-chip interface internal to the core chipset. Our current FCDEV3B hardware (both the existing V1 boards and the upcoming V2) exposes only MCSI and not VSP, and there are no other available Calypso devices on which VSP is accessible, given that it is a private internal interface not meant for application use - thus MCSI is all we have to work with currently.
Back in the late summer of last year I did some experiments with MCSI, and the observation I made back then is that it does not work the way I naively expected it to. I thought that one would enable TI's so-called "Bluetooth headset" mode once at the beginning of a modem session (with the audio_full_access_write() API call with the AUDIO_PATH_USED parameter) and then keep it enabled continuously as the modem alternates between idle and in-call states in normal operation, but it appears that this is not how TI intended this mode to be used. Instead it appears that in TI's Bluetooth-enabled phones (where MCSI was connected to the Bluetooth chip for the digital voice channel) their Bluetooth software stack would enable and disable the Bluetooth headset audio routing mode as the phone goes into and out of a Bluetooth call. If one enters the BT headset mode upfront and stays in that mode, the following issues occur: 1) The modem cannot enter deep sleep while MCSI is on, and has to do big sleep instead, without stopping the 26 MHz VCXO; one can see that this behaviour occurs as the debug trace output from L1 will contain "big sleep" lines with a (cause:DSP) indication. The positive effect of this deep-sleep-suppressing logic is that MCSI clocks aren't being disrupted as the 13 MHz master clock from which they are generated disappears and reappears, but the negative effect is the loss of deep sleep which is quite important for phone-grade power management. The issue will matter on FCDEV3B V2 boards which will hopefully have working sleep, but I was able to experiment with this stuff on my current V1 board by running the firmware out of RAM instead of flash: our V1 sleep mode bug only affects flash. 2) There is a bug in the DSP that causes erratic behaviour if MCSI is turned on when the very first voice call after system boot is being connected. The most visible symptom is that MCSI clock and frame sync signals disappear as seen with an o'scope, but there seems to be some other not-quite-understood breakage happening too, so this condition needs to be avoided. I am guessing that TI probably missed this bug because their Bluetooth software stack issued the command to enter BT handset mode after that critical point in the call establishment process. Back in the summer of last year when I did my initial experiments I saw the latter DSP bug as a show-stopper, but now that I am reconstructing a plausible sense of how TI intended this mode to work, I am having new thoughts. As of just a few days ago I was intent on giving up on MCSI and pursuing the path of tapping into VSP as an alternate way to get the desired digital voice channel, but producing a board with VSP brought out would require an invasive PCB layout change costing thousands of dollars in hired layout labor plus the cost of yet another fab cycle, and because that cost would be more than I can justify spending out of my personal budget, practically the whole digital voice interface idea would hang in limbo until some indefinite time when and if someone else needs it badly enough to pay the cost - obviously a very unattractive situation. But now I am thinking that we may be able to salvage MCSI and make it work after all. How can we make MCSI work acceptably if there is a bug in the DSP? The answer is that it would need to be hidden from the user through some added magic in our Calypso ARM firmware. Our current experimental AT@VPATH command gives the user raw access to TI's audio mode setting, and if the user sets AT@VPATH=2 upfront and then makes a voice call, the DSP bug is triggered - not acceptable. But I am now thinking about creating a new "smart MCSI" mode: if this new mode is set, our L1 code will automatically enable MCSI when a call is connected and disable it when a call ends, just like TI's original code did for actual Bluetooth, and if we do the MCSI enable step at the right point, we should be able to reliably avoid hitting the DSP bug. The externally visible effect will be that MCSI clocks will only be active during calls and will be held low by the pull-down resistors during idle, and deep sleep will work, which is the behaviour we want for a modem that can be used in libre smartphone projects. However, before I go ahead and expend the design and coding effort to implement the above proposed logic in our fw, I need to do one more experiment. So far we know that the MCSI clocks (bit clock and frame sync) are good because I have observed them with an o'scope, but we have yet to verify that MCSI_TXD puts out the voice downlink bits we expect and that we can feed our voice uplink bits to MCSI_RXD. To test these payload paths I need more than an oscilloscope, and my idea is to connect our MCSI to an McBSP port on the OMAP processor on the readily available and inexpensive BeagleBoard-xM. The only difficulty with this idea is that the OMAP on BB-xM has 1.8 V I/O pins which are not tolerant of Calypso's 2.8 V I/O, and in the other direction Calypso's 2.8 V inputs won't work reliably with 1.8 V signals, hence we will need to build a little adapter board with logic voltage level translating buffers. The BeagleBoard has a 28-pin expansion connector on its bottom side; our adapter board will need to have header pins that will go into that female connector, as well as our own headers that will connect to MCSI and optionally to the MODEM UART on an FCDEV3B. The BB-xM expansion interface provides 5 V and 1.8 V, we will need our own regulator to make 2.8 V from the 5 V supply, and we will need logic voltage level translating buffers in both directions. If anyone from the community feels like contributing and can design and build this little adapter for me, that would be awesome, otherwise I will probably come back to it in another few months after we get FCDEV3B V2 boards made. Hasta la Victoria, Siempre, Mychaela aka The Mother _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community