Introduction
This page explains how @trip communicates to the device. @trip is the tool from Mobile Action for monitoring and controlling the GT-800 and GT-800Pro. I am not happy with this tool, which is the primary reason why I created the U-gotMe tool ;-). This is a very, very boring page, simply listing the commands that are exchanged. It is meant for those of you who want to know the exact sequences in order to write own software…
Setup
- @Trip version
- Version 3.5 Build 1111.2967
- Device
- GT-800Pro, Firmware version 7.11
- Track points in memory
- ~5300 (changed during testing)
- Tool used
- PortMon
Starting @trip
NmeaSwitchCommand(0x03)
Request 93 01 01 03 00 00 00 00 00 00 00 00 00 00 00 68
Response 93 00 00
This sets the device in configure mode (whatever it might be. Whithout this mode it still does the jobs…)
ReadCommand(0x000000, 0x1000)
Request 93 05 07 10 00 04 03 00 00 00 00 00 00 00 00 4A
Response 93 10 00 AF 23 10 00 05 00 0F 00 FA 00 28 …
This reads the 1st block in memory, which contains settings, etc
ModelCommand
Request 93 05 04 00 03 01 9F 00 00 00 00 00 00 00 00 C1
Response 93 00 03 C2 20 17
Gets information about the model
IdentificationCommand()
Request 93 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 63
Response 93 00 0A 88 CF 10 00 07 0B 00 08 B2 2A
Get serial numbers and version numbers
UnknownCommand (GT800)
Request 93 10 00 00 00 00 00 00 00 00 00 00 00 00 00 5D
Response 93 00 1A 44 B3 10 00 FE 80 16 10 A1 56 2A 18 00 00 59 00 FF FF AE 3B 2A 18 00 00 0C 25
Not clear
CountCommand
Request 93 0B 03 00 1D 00 00 00 00 00 00 00 00 00 00 42
Response 93 00 03 00 14 B1
Number of records in memory: 5297
ReadCommand(0x000000, 0x1000)
Request 93 05 07 10 00 04 03 00 00 00 00 00 00 00 00 4A
Response 93 10 00 AF 23 10 00 05 00 0F 00 FA 00 28 …
Reads the 1st block again…
Stopping @trip
NmeaSwitchCommand(0x00)
Request 93 01 01 00 00 00 00 00 00 00 00 00 00 00 00 6B
Response 93 00 00
This sets the device in dongle mode…
Downloading tracks
Apparently the program first scans the memory to look for the end of the track log. This is odd because the number of track log records can be requested (maybe the scan has something to do with the caching mechanism (see end of this section)). The scan is executed by reading the 1st 32 bytes of a number of blocks.
ReadCommand(0x020000, 0x0020)
Request 93 05 07 00 20 04 03 02 00 00 00 00 00 00 00 38
Response 93 00 20 00 CB 22 00 90 88 00 0B 00 00 2F 63 1F BD 98 9E 03 ED 3C 8D FF FF FC 77 01 11 5A A2 29 A8 7D 00
ReadCommand(0x001FE0, 0x0020)
ReadCommand(0x002FE0, 0x0020)
…
ReadCommand(0x02AFE0, 0x0020)
ReadCommand(0x02B000, 0x0020)
ReadCommand(0x02B020, 0x0020)
Now the actual read of the track log takes place by reading 0x1000 chunks
starting from address 0x001000 (start of track log memory).
ReadCommand(0x001000, 0x1000)
Request 93 05 07 10 00 04 03 00 10 00 00 00 00 00 00 3A
Response 93 10 00 F1 C7 B2 98 D2 F0 56 45 52 3A 53 65 70 20 33 30 …
ReadCommand(0x002000, 0x1000)
…
ReadCommand(0x02A000, 0x1000)
@trip caches the downloaded block in c:\Documents and Settings\User\Application Data\MobileAction\atrip\raw\deviceID\.
The directory deviceID is for example 8_1101704 (8 underscore ID of the device). Each block is saved in 0.raw, 1.raw ….
On subsequent donwloads only the new data is downloaded.
Erasing track log
@trip starts erasing with a scan of the track log memory, starting at the high end. It scans for the 1st block that is not empty by reading the first 16 bytes of the block.
ReadCommand(0x06F000, 0x1000)
Request 93 05 07 00 10 04 03 6F F0 00 00 00 00 00 00 EB
Response 93 00 10 A6 2D 0F 21 AF FB 0F 12 F1 98 1E D2 B2 CE 28 B3
Ah! Here it goes wrong. @trip probably checks for 16 0xff bytes. However, empty blocks do not contain 0xff’s, but one of four sequences!! Anyway, @trip thinks the last block is not empty and starts erasing from here, all the way down to the 1st block (0x001000).
UnknownWriteCommand1(purge)
Request 93 06 04 00 00 01 06 00 00 00 00 00 00 00 00 5C
Response 93 00 00
WriteCommand(0x6FF000, 0x0000, 0x20)
Request 93 06 07 00 00 04 20 00 10 00 00 00 00 00 00 2C
Response 93 00 00
UnknownWriteCommand2(0x0001)
Request 93 05 04 00 01 01 05 00 00 00 00 00 00 00 00 5D
Response 93 00 01 00
…
UnknownWriteCommand1(purge)
Request 93 06 04 00 00 01 06 00 00 00 00 00 00 00 00 5C
Response 93 00 00
WriteCommand(0x001000, 0x0000, 0x20)
Request 93 06 07 00 00 04 20 00 10 00 00 00 00 00 00 2C
Response 93 00 00
UnknownWriteCommand2(0x0001)
Request 93 05 04 00 01 01 05 00 00 00 00 00 00 00 00 5D
Response 93 00 01 00
Upload route
Upload firmware – Start RomTool
Firmware is uploaded by the RomTool. The RomTool is triggered from @trip.
Upload firmware – The download
The firmware is stored in .bin file in the c:\program files\mobile action\atrip\ directory. For example: FW_GT800P_E_716.bin for the GT-800Pro and FW_GT800_E_616.bin for the GT-800. For the download of the firmware the memory area from 0x601000 onwards is used (for 7.17 0x601000 to 0x694000 is used). Device memory is written in 0x100 (=256) byte blocks. After 0x1000 (=4096 bytes or 16 256 byte blocks) bytes have been written, the entire 0x1000 block is read back, probably for verification.
InternalMemoryRead
Request 93 05 04 00 03 01 9F 00 00 00 00 00 00 00 00 C1
Response 93 00 03 C2 20 17
WriteCommand(0x601000, 0x0100, 0x02)
Request 93 06 07 01 00 04 02 60 10 00 00 00 00 00 00 E9
Response 93 00 00
– Chunk 1:
Request F7 B3 2A 89 90 0E 26 C6 1F D1 86 F2 0C E3 9D 25
Response 93 00 00
– Chunk 2:
– …
– Chunk 17:
WriteCommand(0x602000, 0x0100, 0x02)
…
WriteCommand(0x601F00, 0x0100, 0x02)
ReadCommand(0x601000, 0x1000) (probably for verification…)
Request 93 05 07 10 00 04 03 60 10 00 00 00 00 00 00 DA
Response 93 10 00 F7 B3 2A 89 90 0E 26 …
…
WriteCommand(0x693000, 0x0100, 0x02)
WriteCommand(0x693100, 0x0100, 0x02)
…
WriteCommand(0x693F00, 0x0100, 0x02)
ReadCommand(0x693000, 0x1000) (probably for verification…)
After that, the block at 0x600000 is written. This block contains, the trigger sequence (0x8877AA55), the length of the bin file and the checksum. The latter block triggers the firmware writing.