Revisiting Calypso MCSI

Mychaela Falconia mychaela.falconia at gmail.com
Fri Oct 19 08:06:34 UTC 2018


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 at VPATH command gives the user raw access to TI's audio mode setting,
and if the user sets AT 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


More information about the Community mailing list