The phone uses a Qualcomm MSM6500 chip for cellular CDMA communications.
Hardware interconnects
The PXA's FFUART port is attached to the phone. The connection carries phone commands.
The PXA's USB Host controller also communicates with the phone. It is thought that a second serial port comes up via the USB connection.
There are 4 PXA gpios that appear to be related to phone activity: gpio<11> / gpio<19> are inputs and gpio<48> / gpio<83> are outputs. There are also 2 egpios (pin 25/3) that appear to be phone related.
Finally, note that it is possible that not all gpios and functions have been fully mapped, so there may be other unknown interfaces.
HaRET features
All the information on this page is the result of observing wm5 behavior using the HaRET tool. The HaRET version used to obtain these traces was v0.5.1.
Please note that it is very easy to destabilize wm5 (and potentially the phone hardware) from within haret. You've been warned!
Use haretconsole
Within the haret distribution, one can find the haretconsole python script. This script runs on a linux host computer (not the pda). It can make it easier to use haret. It also has the nice ability to log results and process them into readable strings. The traces on this page were generated using these scripts.
How tracing is done
Within haret it is possible to trap PIO reads and writes to hardware. For example, the FFUART can be monitored with the following commands:
addlist mmutrace p2v(0x40100000) ibit irqs 205 # Wifi ibit irqs 25 # DMA (sound) wirq 10
Note that the 10 in "wirq 10" can be replaced with a larger number to watch activity for a longer period of time.
The key part of the above sequence is the line "addlist mmutrace p2v(0x40100000)" this instructs haret to watch reads and writes to the PXA's FFUART serial port.
FFUART traces
Haret commands
addlist mmutrace p2v(0x40100000) ibit irqs 205 # Wifi ibit irqs 25 # DMA (sound) wirq 10
The results can be post-processed on a linux host machine by running the "scanserial.py" script in the haretconsole directory. For example:
./scanserial.py 0x40100000 < ../haretlog-20060827_150511.log | less
Incoming call
Note: the incoming phone number is obscured to 9998887777.read: '$HTC_SYSTYPE: 2,2,1,2,3\r\n' read: '$HTC_CSQ: 5,5\r\n' read: '+CRING: VOICE\r\n' read: '+CLIP: "9998887777",129\r\n' write: 'AT+CLCC\r' read: '+CLCC: 1,1,4,0,0,"9998887777",129\r\n' read: '0\r' write: 'AT+CPAS\r' read: '+CPAS: 3\r\n' read: '0\r'
Several of the above repeat as the phone rings. If the caller hangs up before answering the phone the following results:
read: '$HTC_PRIVACYCHG: 1\r\n' read: '$HTC_SYSTYPE: 3,2,1,2,3\r\n' write: 'AT+CPAS\r' read: '+CPAS: 0\r\n' read: '0\r' write: 'AT+CLCC\r' read: '0\r' write: 'AT+CMUT?\r' read: '+CMUT: 0\r\n' read: '0\r'
Outgoing call
Note: the outgoing phone number is obscured to 9998887777.write: 'AT+HTC_AUD_PATH=2\r' read: '0\r' write: 'AT+CMUT=0\r' read: '0\r' write: 'ATD9998887777;\r' read: '0\r' write: 'AT+CLCC\r' read: '+CLCC: 1,0,2,0,0,"9998887777",129\r\n' read: '0\r'
The "AT+CLCC" command and response continues periodically until:
read: '$HTC_SYSTYPE: 2,2,1,2,3\r\n' read: '$HTC_CSQ: 5,5\r\n' read: '+COLP: "9998887777",129\r\n' read: '$HTC_PRIVACYCHG: 1\r\n' read: '$HTC_CSQ: 5,5\r\n' write: 'AT+CLCC\r' read: '+CLCC: 1,0,0,0,0,"9998887777",129\r\n' read: '0\r' write: 'AT+CLCC\r' read: '+CLCC: 1,0,0,0,0,"9998887777",129\r\n' read: '0\r'
At this point the phone is connected. Note that the phone call is connected even when it is "ringing". There is little FFUART activity during the call. When the caller hangs up the following happens:
write: 'ATH\r' read: '0\r' read: '$HTC_PRIVACYCHG: 1\r\n' read: '$HTC_SYSTYPE: 3,2,1,2,3\r\n' write: 'AT+CLCC\r' read: '0\r' write: 'AT+CLCC\r' read: '0\r' write: 'AT+CLCC\r' read: '0\r' write: 'AT+CMUT=0\r' read: '0\r' write: 'AT+CMUT?\r' read: '+CMUT: 0\r\n' read: '0\r'
Turn off phone
write: 'AT+CLVL=204\r' read: '0\r' write: 'AT+CFUN=66\r' read: '0\r' read: '$HTC_CSQ: 1,5\r\n' read: '$HTC_SYSTYPE: 0,0,0,0,3\r\n' read: '+CREG: 0\r\n' read: '$HTC_CSQ: 0,0\r\n' *** turn egpio pin 9 on *** turn egpio pin 9 off
Turn on phone
Note: some of the binary strings have been obscured. Where they have, the string <... NN bytes ...> has replaced them.*** turn egpio pin 9 on *** turn egpio pin 9 off read: 'AT-Command Interpreter ready\r\n' write: 'ATV0\r' read: '0\r' write: 'ATE0\r' read: '0\r' write: 'ATS0=0\r' read: '0\r' write: 'ATQ0\r' read: '0\r' write: 'ATX3\r' read: '0\r' write: 'AT&C1\r' read: '0\r' write: 'AT&D1\r' read: '0\r' write: 'AT+CMEE=1;+CRC=1;+CR=1;+CMOD=0;+CMUT=0\r' read: '0\r' write: 'AT\r' read: '0\r' write: 'AT+CFUN=1\r' read: '0\r' write: 'ATE0\r' read: '0\r' write: 'AT+CMUT=0\r' read: '$HTC_3GIND: 0\r\n' read: '+CREG: 2\r\n' read: '0\r' write: 'AT+CLIP=1\r' read: '0\r' write: 'AT+CLIR=0\r' read: '0\r' write: 'AT\r' read: '0\r' write: 'AT+CPIN?\r' read: '+CPIN: READY\r\n' read: '0\r' write: 'AT+HTC_RMSL=0\r' read: '+HTC_RMSL: 000000\r\n' read: '0\r' write: 'AT+HTC_ROTKSL=0\r' read: '+HTC_ROTKSL: 000000\r\n' read: '0\r' *** irq 3(USBh1) activity write: 'AT+COPS=0\r' read: '0\r' *** irq 3(USBh1) activity write: 'AT+CLVL=204\r' read: '0\r' write: 'AT+HTC_GPSONE=4\r' read: '+HTC_GPSONE: 3\r\n' read: '0\r'
Then there are 8 revisions of the following "HTC_DM" communications back and forth with the modem. The ascii string contains hex characters and is mostly zeros. It seems to change a little with each revision. The read response generally doesn't match the write command.
write: 'AT+HTC_DM=<... 268 bytes ...>\r' read: '+HTC_DM: <... 268 bytes ...>\r\n' read: '0\r'
Then this sequence, which is a much smaller write, followed by a read that has very few '0' characters:
write: 'AT+HTC_DM=<... 8 bytes ...>\r' read: '+HTC_DM: <... 268 bytes ...>\r\n' read: '0\r'
Then:
read: '+CREG: 1\r\n' read: '$HTC_ERIIND: 1,64,1,0,0,0,2,Verizon Wireless\r\n' read: '$HTC_CSQ: 5,0\r\n' read: '$HTC_SYSTYPE: 2,2,1,0,3\r\n' read: '[MSM] SysTime: 20060827-201656,sign=1,tz=8,raw=0x321cc038\r\n' write: 'AT+COPS?\r' read: '+COPS: 0,2,"31000"\r\n' read: '0\r' read: '+CREG: 1\r\n' read: '$HTC_ERIIND: 1,64,1,0,0,0,2,Verizon Wireless\r\n' read: '$HTC_SYSTYPE: 2,2,1,0,3\r\n' read: '$HTC_CSQ: 5,0\r\n' write: 'AT+COPS?\r' read: '+COPS: 0,2,"31000"\r\n' read: '0\r' read: '$HTC_SYSTYPE: 2,2,1,0,3\r\n' read: '$HTC_CSQ: 5,0\r\n' write: 'AT+COPS?\r' read: '+COPS: 0,2,"31000"\r\n' read: '0\r' read: '$HTC_SYSTYPE: 2,2,1,0,3\r\n' read: '$HTC_CSQ: 5,0\r\n' write: 'AT+HTC_DM=<... 268 bytes ...>\r' read: '+HTC_DM: <... 268 bytes ...>\r\n' read: '0\r' write: 'AT+COPS?\r' read: '+COPS: 0,2,"31000"\r\n' read: '0\r' read: '$HTC_SYSTYPE: 2,2,1,0,3\r\n' read: '$HTC_CSQ: 5,0\r\n' write: 'AT+COPS?\r' read: '+COPS: 0,2,"31000"\r\n' read: '0\r' read: '$HTC_SYSTYPE: 2,2,1,0,3\r\n' read: '$HTC_CSQ: 5,0\r\n' read: '$HTC_SYSTYPE: 3,2,1,2,3\r\n' read: '$HTC_CSQ: 5,5\r\n' write: 'AT+COPS?\r' read: '+COPS: 0,2,"31000"\r\n' read: '0\r' read: '$HTC_SYSTYPE: 3,2,1,2,3\r\n' read: '$HTC_CSQ: 5,5\r\n'
Signal strength change
-
4 bars:
read: '$HTC_CSQ: 5,4\r\n'
-
5 bars:
read: '$HTC_CSQ: 5,5\r\n'
Info trace
Some interesting information is sent to/from the modem when clicking on the "phone settings" menus:Note: the phone number of the pda itself is obscured to 9998887777.
write: 'AT+CFUN?\r' read: '+CFUN: 1\r\n' read: '0\r' write: 'AT+CNUM\r' read: '+CNUM: ,"9998887777",129\r\n' read: '0\r' write: 'AT+HTC_VPRIVACY=4\r' read: '+HTC_VPRIVACY: 0\r\n' read: '0\r' write: 'AT+HTC_GPSONE=4\r' read: '+HTC_GPSONE: 3\r\n' read: '0\r'
Time trace
If one clicks on "time synchronization" under the phone settings menu the follow occurs when clicking "update now":
write: 'AT+HTC_GETSYSTIME=0\r' read: '+HTC_GETSYSTIME: 06,09,17,01,04,42,1,8\r\n' read: '0\r'
Location Setting trace
From phone settings menu, query "Location Setting" while "location on":
write: 'AT+HTC_GPSONE=4\r' read: '+HTC_GPSONE: 0\r\n' read: '0\r'
Query while "911 only":
write: 'AT+HTC_GPSONE=4\r' read: '+HTC_GPSONE: 3\r\n' read: '0\r'
Set "911 only":
write: 'AT+HTC_GPSONE=3\r' read: '+HTC_GPSONE: 3\r\n' read: '0\r'
Set "Location on":
write: 'AT+HTC_GPSONE=0\r' read: '+HTC_GPSONE: 0\r\n' read: '0\r'
TTY mode trace
Query:
write: 'AT+HTC_TTYMODE=4\r' read: '+HTC_TTYMODE: 3\r\n' read: '0\r'
Set disabled:
write: 'AT+HTC_TTYMODE=3\r' read: '+HTC_TTYMODE: 3\r\n' read: '0\r'
Set "alert" trace
Query:
write: 'AT+HTC_SVC_TONE?\r' read: '+HTC_SVC_TONE: 1\r\n' read: '0\r'
Save enabled:
write: 'AT+HTC_SVC_TONE=1\r' read: '0\r'
Save disabled:
write: 'AT+HTC_SVC_TONE=0\r' read: '0\r'
Preferred Servicing System trace
Query: (Note obscured number to 1234567890)
write: 'AT+HTC_PSS?\r' read: '+HTC_PSS: 255,1234567890\r\n' read: '0\r'
Save as "Automatic":
write: 'AT+HTC_PSS=255,1234567890\r' read: '+HTC_PSS: 255,1234567890\r\n' read: '0\r'
Save as "Home only":
write: 'AT+HTC_PSS=1,1234567890\r' read: '+HTC_PSS: 1,1234567890\r\n' read: '0\r'
Incoming text message
Arriving text messages show up on the serial port as a long ascii string of hex characters. It is unclear how this hex string is decoded.
read: '+CMT: ,167\r\n' read: '<... 334 bytes ...>\r\n'
EvDO disconnect
write: 'ATH\r' read: '0\r' write: 'AT+CLCC\r' read: '+CLCC: 9,0,2,1,0,"#777",129\r\n' read: '0\r' write: 'AT+CLCC\r' read: '+CLCC: 9,0,2,1,0,"#777",129\r\n' read: '0\r' read: '$HTC_3GIND: 1\r\n' read: '3\r$HTC_3GIND: 0\r\n' write: 'AT+CLCC\r' read: '0\r'
EvDO messages
After an idle condition ends an data is actively received, the following message occurs:
read: '$HTC_3GIND: 1\r\n'
After the connection goes idle again, the following occurs:
read: '$HTC_3GIND: 2\r\n'
Todo
-
Trace sending text message
-
Trace answering phone call (incoming/outgoing)
-
Trace voice mail indicator being sent
-
Trace 1x / EVDO status changes
USB host traces
No tracing has been done yet. As a guess, this serial port may be related to data network access.
GPIO pins
gpio<11> : Input pin - Unknown purpose - seen to toggle
gpio<19> : Input pin - Unknown purpose - Phone seems to drive high during command sessions. (Seems similar to egpio<3> but doesn't wait as long to go low.)
gpio<22> : Output pin - Unknown purpose - toggles during suspend/resume and during modem shutdown
gpio<48> : Output pin - Unknown purpose -- off during suspend and while phone shutdown
gpio<83> : Output pin - WinCE drives this pin low before writing to the FFUART and then brings it high after the write is complete. It is also driven low before suspending.
egpio<3> : Input pin - The phone seems to drive this pin high for duration of FFUART traffic with phone. It goes low several seconds after the FFUART traffic has idled (eg, if the phone call ends).
egpio<25> : Output pin - Toggles when phone is being turned on/off
Advanced HaRET tracing
It is possible to use more advanced haret scripts that monitor more than just the serial port. One use of this is to monitor reads and writes to the serial port while simultaneously monitoring gpio pins. Due to the nature of the HTC Apache's CPLD and PXA gpios this can be a little complex.
Sample haret script:
# Watch serial port addlist mmutrace p2v(0x40100000) ibit irqs 205 # Wifi ibit irqs 25 # DMA (sound) # Watch writes to egpio output registers addlist mmutrace p2v(0x0a000002) 2 'rw' ~0x204 addlist mmutrace p2v(0x0a000004) 2 'rw' ~0xc13 # Poll for gpio changes joinlist traces gpios ibit traces 0..9999 wbit traces 1 11 19 20 21 22 27 48 79 80 83 86 88 96 98 wbit traces 128+1 128+11 128+19 128+20 128+21 128+22 128+27 128+48 128+79 128+80 128+83 128+86 128+88 128+96 128+98 wbit traces 512+3 512+4 # Force poll when cpu reads/writes to gpio registers. addlist mmutrace p2v(0x0a000000) 0x20 '' addlist mmutrace p2v(0x40E00000) 0x200 '' wi 10
The first block of code watches the FFUART serial port and ignores some unrelated irqs. This block is unchanged from the earlier examples.
The second block watches changes to the cpld output egpio pins. The output pins on the CPLD chip are write only, so normal gpio polling (eg, via "watch") will not show changes to these output pins. So, the script instead traps WinCE writes that may change the settings. The "'rw'" indicates that haret should trap both reads and writes. The "~0x204" will cause haret to not report an access if it one of the specified bits doesn't change. (This allows the script to mask accesses to unrelated bits.)
The third block causes HaRET to poll for changed gpio events on every exception that the processor handles. The script copies the gpio definitions from the GPIO variable into the TRACES variable - TRACES is the variable polled on every exception during wirq. To simplify the script, every gpio is ignored and then only those gpios that are of interest are unignored. Note that the gpios listed are all the "not sure what they do" gpios on the Apache. Also, 128 just happens to be the start of the GPIO direction bits in haret, and 512 just happens to be the start of the input cpld bits.
Finally, the fourth block adds a couple of "dummy" mmutrace entries. These mmutrace events wont report anything, because neigher read nor write accesses were requested (instead of "rw" there is just ""). This causes haret to trap those accesses, but not report them. Instead, the traps force the polling definitions (defined in the third block) to run whenever the WinCE code accesses the registers. The net effect is that we cause the gpio polling to occur more frequently and at the right times.
Some sample output (post scanserial.py):
HaRET(31)# wi 30 ... 005.478(1656983) TRACES GPLR2: GPIO83(83)=0 005.482(0031041) TRACES GPLR2: GPIO83(83)=1 005.485(0010075) TRACES GPLR0: GPIO19(19)=1 005.485(0000437) IRQS ICIP: FFUART(22)=1 005.488(0020996) IRQS cpldA: CA11(203)=1 005.488(0000000) TRACES cpldA: CA3(515)=0 005.490(0017739) TRACES GPLR2: GPIO83(83)=0 005.588(0630319)-005.588(0001325) write: 'AT+HTC_AUD_PATH=2\r' 005.588(0000153) IRQS ICIP: FFUART(22)=1 005.588(0001018) TRACES GPLR2: GPIO83(83)=1 005.588(0050698) IRQS ICIP: FFUART(22)=1 005.588(0000924)-005.588(0000179) read: '0\r' 005.666(0379882) TRACES GPLR2: GPIO83(83)=0 005.666(0000435)-005.666(0000701) write: 'AT+CMUT=0\r' 005.666(0000156) IRQS ICIP: FFUART(22)=1 005.666(0001068) TRACES GPLR2: GPIO83(83)=1 005.666(0025734) TRACES GPLR0: GPIO11(11)=1 005.666(0000115) TRACES GPLR0: GPIO11(11)=0 005.666(0003288) IRQS ICIP: FFUART(22)=1 005.666(0001183)-005.666(0000171) read: '0\r' ...
