MCSI works in master mode

[Mychaela Falconia]

Hello FreeCalypso community,

I have done some more experiments and made some additional discoveries
regarding the "Bluetooth" digital voice interface on Calypso MCSI.

One of the questions I was seeking to answer was whether this BT mode
is already a part of DSP ROM version 3606 in the Calypso silicon, or
if it gets added by the DSP patch code we got from TCS211.  I performed
an experiment: I built a hacked-up fw version that has all DSP patch
downloads (both static and dynamic) disabled, so that the DSP only runs
its ROM code, and tried enabling the BT headset mode (AT at VPATH=2) with
this fw.  Observed result: issuing that command caused the 520 kHz
clock to appear on the MCSI_CLK line just like with the regular
unhacked Magnetite fw.  Thus the bits in the d_audio_init DSP API NDB
word which the TCS211 L1 source defines as BT *are* understood and
acted upon by the unpatched DSP ROM 3606.

However, as I was playing around I made another discovery that is more
unpleasant: there appears to be a bug in the DSP code (the symptoms
are the same with or without the TCS211 patches) such that if the BT
headset mode is enabled before the first GSM voice call, the mode
appears to get dropped during the establishment of that first call.
The visible symptom is that if I issue AT at VPATH=2 before bringing up
GSM, the 520 kHz clock appears on the oscilloscope display, that clock
stays as I enable the SIM with AT+CFUN=1 and connect to the GSM network
with AT+COPS=0, but as soon as I dial the first voice call, that clock
on MCSI_CLK disappears.  But the AT at VPATH? query which checks the bits
in the d_audio_init DSP API NDB word still returns 2, meaning the BT
headset mode.

If the erratic state described above (AT at VPATH? returns 2 but there is
no clock on MCSI_CLK) has been entered, one can recover by setting
AT at VPATH first to 0 or 1 and then back to 2.  Simply repeating the
AT at VPATH=2 command without selecting one of the other modes first does
nothing.  Once this switch-back-and-forth recovery has been done,
subsequent voice calls do not cause MCSI_CLK to disappear, i.e., the
clock stays like it should.

A different workaround which feels cleaner to me is to delay issuing
the initial AT at VPATH=2 command (selecting BT headset mode) until the
first voice call has been connected or at least got its TCH assigned
and vocoder enabled.  (The %CPI call progress indications say when
this point is reached.)  With this sequence the erratic state does not
get entered.

The proper solution would be to track down the bug in the DSP code and
fix it in the patch code, but doing so would require either buying out
the source for the DSP ROM from TI (which brings us back to needing
millions of dollars just to get their attention) or expending a
Herculean effort to reverse-engineer that ROM.  So we are most likely
going to be stuck with workarounds for quite a while.

It also needs to be kept in mind that so far we have absolutely no
proof that this "Bluetooth" digital voice interface actually works at
all: we know that a 520 kHz clock gets put out on MCSI_CLK and that
there is an 8 kHz frame sync on MCSI_FSYNCH, but we still don't know
if the actual voice downlink gets put out in any usable form on the
MCSI_TXD pin or if the voice uplink gets taken from the MCSI_RXD pin
like one would expect.  We do know for sure that the hardware is
perfectly capable of doing what we want (or at least what I want),
which is putting out the voice downlink in the native 16-bit linear
PCM format on MCSI_TXD and taking the voice uplink in the same format
from MCSI_RXD, but we still don't know if there are any more bugs,
misfeatures or incomplete implementation in the DSP code that would
get in the way.

I feel that the most sensible next step in this investigation should
be to connect the Calypso MCSI signals from an FCDEV3B to a
BeagleBoard, specifically BB-xM.  The OMAP processor on the BB (DM3730
on BB-xM) has McBSP interfaces which appear to be ideally suited for
such applications, thus if we connect our MCSI to one of the OMAP
McBSP ports on the BB-xM and put that McBSP into the clock slave mode,
we should be able to use the Linux environment on the BB-xM to look at
the supposed voice data coming out of the MCSI_TXD pin, and if we
actually get some sensible voice data there, try feeding our own voice
uplink data back in the same format.

It will be a lengthy process though, as I would need to do a whole
bunch of preparatory steps first:

* Gain the ability to read and write uSD cards on my laptop, as uSD is
  a requirement for working with the BB-xM;

* Buy a BB-xM and become comfortable playing with it to the point where
  I can hack its Linux kernel to put the pinmux and McBSP modules into
  the needed config;

* Design and build a special adapter PCB that would connect the BB-xM
  expansion interface (on the bottom of the BB-xM) to our MCSI,
  including the necessary level shifters between OMAP's 1.8V and
  Calypso's 2.8V, as well as a local 2.8V regulator (powered from BB's
  5V rail) for those level shifters.  It would be a very simple board,
  but we would still have to go through the gymnastics of making a
  custom PCB.

I am hoping to get started on the first step (uSD cards) some time
soon-ish...

Hasta la Victoria, Siempre,
Mychaela aka The Mother