Please remember to add a category to the bottom of each page that you create.
See categories help for further details, but most will probably be [[Category:HTC ModelName]].


From XDA-Developers
Jump to: navigation, search

wasic3gpio watching is at:

from this, we can definitely deduce that BTUART is used as the serial port to communicate with the GSM module.

oh _great_. this is a gnuharet wi trace of the BTUART data, decoded: and it shows some ridiculous binary data, indicating that there's multiplexing going on. greaat. i am very reassured.

enabling GSM AT command logging in wince with phm regedit, which you can use to set SOFTWARE\OEM\ATDbgLog.

13nov2006: oh, arse: as i suspected, BTUART data is sent in between the GPIO signals. ok, other than that little pain in the arse, here's some raw data from a wi trace, off the btuart:

actually, two wi traces were actually carried out: one which captured btuart IRQs and GPIOs, and another which captured btuart irqs and btuart send/receive data. here's the second one:

it can clearly be seen that there is an initialisation sequence. also it can be seen that there is a 0x02 'command', followed by a 2-byte LSB length field, in the request.

also it can clearly be seen, in the response, that there is a 0x81 'command'.

so, so far, it looks like this:

<0x02> <2-byte length, LSB first> <command-byte> <0x00> <2-byte crc checksum>

<command-byte>s seen so far include 0x00, 0x81 and 0x82.

at least two 0x82 responses has been seen, unsolicited: 80 cc cb was the first, and 2b 43 47 52 45 47 3a 20 34 0d a8 70 which is "+CGREG: 4" in ascii, was the second.

the crc is a 16-bit crc checksum, running from <command-byte> through to the end of the data, and the initial lead-in crc value is 0xffff. i found some random c-code with a crc16 algorithm in it, that is 'Derived from CRC algorithm for JTAG ICE mkII, published in Atmel Appnote AVR067' - i've dumped the whole lot at:

you compile it with gcc serial.c and run ./a.out (of _course_ you use linux)


crc16.c comes from: