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@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@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@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@VPATH? returns 2 but there is no clock on MCSI_CLK) has been entered, one can recover by setting AT@VPATH first to 0 or 1 and then back to 2. Simply repeating the 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@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 _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community