devicename | driver | uart address | irq | connects to |
---|---|---|---|---|
COM1: | serial.dll | a8030000 | 0010 | external serial cable |
COM3: | ircomm.dll | infrared port | ||
COM2: | serial3.dll | a8050000 | 000f | gsm multiplexed protocols |
COM8: | usb.dll | a8000000 | 000d | serial over USB |
COM9: | serial2.dll | a8010000 | 0011 | gsm bootloader |
DeviceIoControl (hCom,0xAAAA5679L, {0x84,0}, 2,0,0,0,0)
command | protocol channels supported |
---|---|
normal | 11 14 16 17 |
dualtrace | 11 14 17 |
dual | 11 14 17 |
protocol | description |
---|---|
11 | trace messages |
12 | other gsm trace |
13 | PCO trace |
14 | unknown |
16 | gsm at commands |
17 | peripheral control ( led, vibrator, battery) |
Wait for turn on GSM... GSM already on -> RESET !! GSM turn on successed!! -----------------------ULYSSE MODE--------------------------- Normal mode(UART2 --- UART3) ****************************************************** InitDebugSerial using SERIAL PORT 2 ****************************************************** GSM RESET...after which things get interesting: in hex:
02 11 00 00 00 20 03 "Trace module started by the environment" 02 02 11 00 00 00 00 01 "RVT: Lost Message" 02 02 17 "4D01FF00004D" 02 02 16 "AT-Command Interpreter ready\r\n" 02now there are several things I can do:
request | reply |
---|---|
11 02 | Exception: Unexpected Software Interrupt
this seems to crash the gsm |
14 02 | 02 14 00 10 10 10 10 02 |
17 02 | 02 17 "0000" 02 |
16 "at%ureg?0,4\r" 02 |
02 16 "a" 02 02 16 "t%ureg?0,4\r\r\n\r\n" "+EXT_UREG EA000446\r\n\r\n\r\n" "OK\r\n" 02 |
these devices are available I think:
address | description |
---|---|
1 | led/vibrator |
2 | unknown |
5 | battery via cal |
7 | unknown |
8 | unknown |
9 | phone audio control |
b | unknown |
d | battery via ssp |
in replies, the length+device nyble are followed by a hex-status byte, followed by <length> result bytes
sequence | action |
---|---|
51 00 00 00 00 00 | led off |
51 00 01 01 05 05 | red led on |
51 00 00 01 05 05 | red led off |
51 01 01 01 05 05 | green led on |
51 01 00 01 05 05 | green led off |
51 02 01 01 05 05 | orange led on |
51 02 00 01 05 05 | orange led off |
51 03 01 00 01 00 | vibrator on |
51 03 00 00 01 00 | vibrator off |
19 xx | phone mode ? something audio related |
0d | request battery status via scc answer: 4D0180021FEF |
05 | request battery status via cal answer: 45FFFF0274B9 |
the code in the gsm rom handling this protocol is in the first 4K of the gsm rom. this code is never updated(well, not that I have seen) by radio stack upgrades, thus always leaving an option to rescue your radio stack if something went wrong upgrading.
I have not yet figured out what rsupgrade does to be able to talk to com9:
I think I did everything the same as I see rsupgrade doing, it just doesn't work for me.
the general request format is:
position | value | description |
---|---|---|
0 | 0xaa | header byte |
1 | length byte | |
2 | 0x00 .. 0x0b | command byte |
>=3 | data, if 0xaa occurs, it is escaped by doubling it |
position | value | description |
---|---|---|
0 | 0xaa | header byte |
1 | length byte | |
2 | 0x00 .. 0x0b | command byte |
3 | status byte, 0x00= OK | |
>4 | data, if 0xaa occurs, it is escaped by doubling it |
below the packet formats, ( leaving out the '0xaa' )
with the number of 'x' specifying how many digits in each parameter.
command | request format | answer format | |
---|---|---|---|
cmd00 | get_monitor_id | 01 00 | 05 00 00 ii mi ma info byte, minor, major version nr |
cmd01 | get_flash_memory_id | 01 01 | 03 01 00 xx |
cmd02 | get_chip_id | 01 02 | 03 02 00 xx |
cmd03 | get_board_id | 01 03 | 03 03 00 xx |
cmd04 | erase_flash_memory | 01 04 | 01 04 |
cmd05 | write_flash_memory | 01 05 | 10 05 00 xxxx xxxx xxxxxxxx first 16bit word is a checksum, last 32bit word is a crc |
cmd06 | 01 06 | 03 06 00 xx | |
cmd07 | read_parameters | 04 07 xxxx xx | ?? 07 00 xx [xxxx ...] |
cmd08 | write_parameters | ?? 08 xxxx xx [xxxx ...] | 01 08 |
cmd09 | write srecords | 01 09 | 06 09 00 xxxx xxxx first word is file checksum, second is ram checksum |
cmd0a | execute monitor | 05 0a xxxxxxxx | 01 0a |
cmd0b | write_flash_memory | 01 0b | 0a 05 00 xxxx xxxx xxxxxxxx |
on the top line, there are checkboxes, to control this:
DTR, RTS | controls these rs232 lines |
BREAK | sends a break |
Infrared-mode | sets the uart in Infrared mode. |
hex | the input edit box is interpreted as hexadecimal data. |
the next line contains status indicators for this:
DSR,CTS,DCD,RING | the status of these rs232 lines |
BRK | break was detected. - MS Comm api does not tell when the break ends |
RLSD | ? - [see ms docs] |
rcv,xmit | these toggle on and off, with each packet received/sent |
below each of these indicators is a counter, counting how often they have changed
then follows the userinput box, with a 'transmit' button
then a big output window
followed by 2 lines of bit indicators, the first line are the gpio bits, the second line
the port at 0xa4000068 ( with the now I think wrong assumption, that 0xa4000064 controls
the direction of these bits ).
red means it is an input bit, black means it is an output bit. you can switch from
input to output by tap+holding the bit. you can toggle its output value by tapping ig.
a filled square is a '1' bit, an empty squere is a '0'.
playing with these bits may damage your device, so first research by reverseengineering
code that touches them, before just randomly fidling with them.
the bottom is a bit chaotic, and contains experimental checkboxes
ril | send ioctl 0x03000318/0x03000314 to the RIL1: device, |
com | send ioctl 0xaaaa5679 to the current device |
dbg | enable/disable debugging info in the output window |
gsm | controls bit 6 of 0xa4000068 |
mode | controls bit 6 of 0xa4000064 |
mem | toggles the value of 0xac0203c8 between 0 and 1 |
open | opens or closes the selected device |
to enable logging, set these registry keys:
[HKLM\SOFTWARE\HTC\ATDbgLog] Enable=1 [HKLM\SOFTWARE\HTC\XPanel] Enable=1