-
Notifications
You must be signed in to change notification settings - Fork 98
/
Copy pathS1Protocol notes.txt
64 lines (50 loc) · 2.18 KB
/
S1Protocol notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
// PROTOCOL FMT
// ALL DWORDS ARE BIG ENDIAN
[DWORD] CMD (4 bytes)
[DWORD] FLAGS ( 1 | 2 | 4 ) (4 bytes)
[DWORD] LEN (4 bytes)
[BYTE] HDR CHECKSUM (1 byte)
[BYTE[LEN]] DATA (n bytes depending on the LEN value)
[DWORD] DATA CHECKSUM (CRC32) (4 bytes)
FLAGS seems to always be either:
false true false ( 1 | 2 | 0 ) = 3
or
false true true ( 1 | 2 | 4 ) = 7
the 4 indicates whether the command has more data or not.
if the 4 bit is set to true, it means there is more data,
otherwise we are done with command.
COMMANDS:
0x01 - loader info?
0x04 -
0x05 - write SIN header
0x06 - write SIN
0x07 - Get last error ?
0x09 -
0x0A -
0x0C - read TA
0x0D - write TA
Generally, a writeBytes is followed by 2 or 3 readBytes, depending on the length of data in the first readBytes (if LEN = 0 then only 2...)
When calling readBytes, generally we read the header first (CMD, FLAGS, LEN, HDR CKSM),
then the next readBytes contains data of length LEN and is the result of the command.
Finally, the last readBytes is a CRC32 of previously read data.
Example:
//writeBytes cmd = 0x0000000C, flags = 0x00000003, len = 0x00000004, hdr cksm = 0x12
//data = 0x000008A2, data cksm = 0xF00148CC
<< 00, 00, 00, 0C, 00, 00, 00, 03, 00, 00, 00, 04, 12, 00, 00, 08, A2, F0, 01, 48, CC
//readBytes cmd = 0x0000000C, flags = 0x00000001, len = 0x00000005, hdr cksm = 0x0F
header :
>> 00, 00, 00, 0C, 00, 00, 00, 01, 00, 00, 00, 05, 0F
data = X10a\0
>> 58, 31, 30, 61 (X10a\0)
//data CRC32 = 0x1879A4B8
>> 18, 79, A4, B8
loader is sent by part of 4096 bytes.
images are sent by part of 65536 bytes.
The max lenght of a read / write request is 65536 and because of header and crc32, 17 bytes are
reserved.
So to send 65536 bytes of data, you must first send 65536 - 17 then send 17.
Under linux, using libusb, when reading replies, header and data are received in a same read request.
The last read request is a 4 bytes representing the CRC32 of the data section.
To validate a reply :
- calculate the header checksum and compare with the one received.
- caclulate the data CRC32 and compare with the one received.