XDADeveloperWiki - Himalaya GSM

Initial Exploration

Bootloader RadioOff and RadioOn all do an ASIC3 B "OUT" on bit 1 (0x2).

RadioReset does an &= 0xfffd, on ASIC3_B_OUT, sleeps for 100,000, then an |= 0x2, sleep, then &= 0xfffd.

hm, there appears to be a bug in the bootloader :)

okay, sequence is as follows:

set GPDR on pin 21 to high (i.e. out)
set GPSR on pin21 (i.e. set pin 21 high
on asic3 A, set bit 1 direction as an out
on asic3 A, set bit 1 as high.
set GPIO 36 as an OUTPUT.
set GPIO 36 as "not an alt" i.e. not alt1,2 or 3.
set GPIO 36 to high
on asic3 A, set bit 3 direction as an input
on asic3 A, set bit 3 output to low.
on asic3 B, set bit 1 as low, then sleep for 1ms.
on asic3 B, set bit 1 as high, then sleep for 1ms.
on asic3 B, set bit 1 as low, do NOT sleep, go straight to....
set GPIO 36 to an ALT_1 input.

gibber!

okay, according to http://www.xs4all.nl/~itsme/projects/xda/serial-protocols.html, to do multi-protocol over the STUART port, you must send 0x17 AT\r 0x02.

Making phone calls work

okay. initial exploration using gomunicator, which works on the blueangel, had everything working right up to the point where registration was required (sending the PIN number), at which point it all went pear-shaped. So, what I did was to power up haret.exe (hurrah) and make a phone call. I immediately noticed two GPIO pins flipping which are now documented on HimalayaASIC3 as GPIOB13 and GPIOB15, whereupon the mp3 that was playing at the time stopped coming out the speaker.

Basically, I'm guessing that the way it works (on the Blueangel as well) is this: the ASIC3 is responsible for "circuit switching" the audio all over the place. So, for example, with GPIOB13 and GPIOB15 enabled on the Himalaya, I'm guessing that the Mic and Speaker are connected to the audio in/out on the GSM Radio ROM. If you switch another couple of GPIO pins, they get connected to the Headset. And another couple and they get connected to the Bluetooth. I hate to think what would happen if you switched them all on.

Here's one important thing though: it was only when GPIOB13 (or maybe it was GPIOB15) was enabled that the GSM "Pin" number was accepted. When BOTH were on (I can't remember which it was) it didn't work.

The implications are as follows: in gomunicator (or any other phone program) it's going to be necessary to do a user-space connection to the ASIC3, to get audio-switching done at the right time... more later...