Bluetooth to 2410 Wiring

[Wally Ritchie]

On 7/27/07, Ian Stirling <OpenMoko at mauve.plus.com> wrote:
> Harald Welte wrote:
<snip>
>
> I need to do more reading on the CSR hardware in the bluetooth module.
>
> Having said that.
> As I understand, the chip is in principle quite flexible, having FLASH,
> and ROM versions, as well as a flexible development environment.
>
> I do not of course know what the price delta is between FLASH and ROM
> parts, or what the initial cost would be for a ROM part.
>
The so-called ROM version is itself very flexible with parameters contained
on a persistant store. This configures the chip as to what PIO's for what
functions, USB device parameters, etc. etc.

> If it is possible to reroute one of the FPC lines to an interrupt
> capable pin of course.
>
> Find an interrupt device that can be wire-ORed with the wakeup line -
> perhaps the GSM wake?
>
There are two pins involved in DETACH and WAKEUP and as many as
5 involved in WiLan coexistance. There are several versions of this
coexistance some of which are proprietary.

> Configure(if possible) the bluetooth module for weak pullup/down.
>
> Alter the firmware in the module so that it can be switched to 'suspend'
> mode, which changes the meaning of one of the IOs on the FPC to be wakeup.
>
I belive the pio's from the CSR default to weak pull-down but when used for
a function will drive active high or low. It may be possible to share
the pin use
in different modes by re-programming the pin usage on the fly. It's an ugly hack
but it might work.
> If you want woken on GSM interrupts only, turn the bluetooth module off
> first. (it cannot have its power turned off, as otherwise it will
> violate the input voltage conditions with 0V VCC) however the power use
> is really low in this mode - fractions of a milliwatt.
>
> If you want woken only on bluetooth wake interrupts, do the same with
> the GSM module.
>
> If you want to put it to sleep totally, and not wake on either, power
> both down.
>
> This could (potentially) be one additional trace from the existing GPIO
> to an EINT pin, and software changes on the module.
>
There may be interaction with Wake on WiLan if that is supported by the device.
If there is no wake on WiLan, there is probably a way to share the coexistance
pin functions with detach and wakeup. This would be true only if the CSR chip
is not running custom firmware for the coexistance functions - then
all bets are off.

There is a good chance something could be made to work if we can get just one
output pin and one external input pin to the SoC. These could be in
parallel with
the wiring from the BT module to the WiLAN.
>
> To expand more on use-cases.
>
> I want to wake on keypresses on an external keyboard.
> To wake on calls from an external bluetooth modem.
> To wake on coming into range of a known bluetooth device.
>    Getting into car, and having phone start logging your journey
> automatically)
>    Coming into range while wearing a BT headset, and having the phone
> notify you of missed calls.
>
>
The BlueCore4 chip is a very good implementation with multiple SCO
paths. This can
supports mode where we connect a BT headset and another BT device and
route PCM through them.

Cheers, Wally