USB Upload (a little bit special)

Control_transfer_write

requesttype=0x40

value=0x10

length=0x40

data=0x00000000 0x0203 0x40+len1[explained later] [0x00 repeated 0x38]

Example:

0000  00 00 00 00 03 02 7a 14 00 00 00 00 00 00 00 00  ......z.........
0010  8e 58 63 3e 44 2e 43 54 47 00 00 00 00 00 00 00  .Xc>D.CTG.......
0020  00 00 00 00 00 83 85 82 87 84 7f 81 7f 7d 7b 77  .............}{w
0030  7e 81 7e 7d 7c 7d 81 80 82 80 7c 80 81 7f 84 83  ~.~}|}....|.....
      

This is identical to the response to Download Captured Image, except for the cmd3 halfword at 0x04. The cmd3 halfword is 0x0203 here, 0x0302 there.

bulk_in_read [0x40 bytes]

Example:

0000  00 00 00 00 03 03 00 00 00 00 00 00 00 00 00 00  ................
0010  8e 58 63 3e 44 2e 43 54 47 00 00 00 00 00 00 00  .Xc>D.CTG.......
0020  00 00 00 00 00 83 85 82 87 84 7f 81 7f 7d 7b 77  .............}{w
0030  7e 81 7e 7d 7c 7d 81 80 82 80 7c 80 81 7f 84 83  ~.~}|}....|.....
      

The following block obeys the normal command block structure. The exact layout is:

0000000: xx xx xx xx 03 04 00 00 - 00 00 00 00 00 00 00 00
0000010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
0000020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
0000030: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
0000040: 02 00 00 00 03 00 00 11 - xx xx xx xx SS SS SS SS
0000050: 00 00 00 00 UU UU UU UU - VV VV VV VV pathname data ...
      

xx xx xx xx : len1, the length of the payload (total block length - 0x40)

cmd3 = 0x00000403

cmd1 = 0x03

cmd2 = 0x11

xx xx xx xx : len1 (again)

SS SS SS SS : sequence number

UU UU UU UU : Offset within file; starts at zero, increments by len2 (below) for next block

VV VV VV VV : len2, length of data in this block. Normally 0x1400 or less.

pathname : full path name of file on camera, terminated by one NUL. File cannot be created in nonexistent directory.

data : image data (len2 bytes)

Example of beginning of a block:

0000  3a 14 00 00 03 04 00 00 00 00 00 00 00 00 00 00  :...............
0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0040  02 00 00 00 03 00 00 11 3a 14 00 00 a2 4c 10 02  ........:....L..
0050  00 00 00 00 00 00 00 00 00 14 00 00 44 3a 5c 44  ............D:\D
0060  43 49 4d 5c 31 35 38 43 41 4e 4f 4e 5c 41 55 54  CIM\158CANON\AUT
0070  5f 30 30 30 31 2e 4a 50 47 00 ff d8 ff e1 18 ba  _0001.JPG.......
0080  45 78 69 66 00 00 49 49 2a 00 08 00 00 00 09 00  Exif..II*.......
0090  0f 01 02 00 06 00 00 00 7a 00 00 00 10 01 02 00  ........z.......
00A0  ....
      

The filename here is D:\DCIM\158CANON\AUT_0001.JPG; the offset is zero (i.e. this is the first block of this file) and length is 0x1400. Len1 is 0x143a, which is 0x1400 + 0x10 + 0xc (three full words) + 0x1e (length of pathname+1).

Response to this block (0x5c bytes):

0000  00 00 00 00 03 03 00 00 00 00 00 00 00 00 00 00  ................
0010  00 00 00 00 00 00 00 00 78 00 00 00 76 00 00 00  ........x...v...
0020  36 00 00 00 02 02 00 00 00 00 00 00 00 00 00 00  6...............
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0040  02 00 00 00 03 00 00 21 1c 00 00 00 a2 4c 10 02  .......!.....L..
0050  00 00 00 00 00 14 00 00 00 14 00 00              ............
      

The interesting words are:

0x50 Status
0x54 Count of bytes already transferred in this upload?
0x58 Number of bytes of real data transferred in the latest bulk write.

Unfortunately, the number at 0x54 seems to jump too fast; after the second write of 0x1400 bytes, it reads 0x3c00, not 0x2800. And after the next, it's 0x6400, not 0x3c00. In fact, it counts up by multiples of the 0x1400 data length: 1, 3, 5, 7, 9, ...

This transaction is repeated until the whole file is transmitted.

At the end of the transfer, there will usually be one short transfer. Here it is 0x117e bytes:

0000  b8 11 00 00 03 04 00 00 00 00 00 00 00 00 00 00  ................
0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0040  02 00 00 00 03 00 00 11 b8 11 00 00 a2 4c 10 02  .............L..
0050  00 00 00 00 00 4c 04 00 7e 11 00 00 44 3a 5c 44  .....L..~...D:\D
0060  43 49 4d 5c 31 35 38 43 41 4e 4f 4e 5c 41 55 54  CIM\158CANON\AUT
0070  5f 30 30 30 31 2e 4a 50 47 00 02 8a 00 28 a0 02  _0001.JPG....(..
0080  8a 00 28 a0 02 8a 00 28 a0 02 8a 00 28 a0 02 8a  ..(....(....(...
0090  00 28 a0 02 8a 00 28 a0 02 8a 00 28 a0 02 8a 00  .(....(....(....
      

Here the offset is 0x44c00.

The response is 0x5c bytes

0000  00 00 00 00 03 03 00 00 00 00 00 00 00 00 00 00  ................
0010  7a 8c f2 3e 94 98 6a 3b 19 01 14 ee 3d f2 79 14  z..>..j;....=.y.
0020  a0 07 f9 17 0c ab d4 e7 9a 43 bb ec 3c 6d 7e 4e  .........C..<m~N
0030  0a 2f 71 9c d2 ae 1f 32 37 cd 8e 87 1c d1 61 58  ./q....27.....aX
0040  02 00 00 00 03 00 00 21 1c 00 00 00 a2 4c 10 02  .......!.....L..
0050  00 00 00 00 7e a9 08 00 7e 11 00 00              ....~...~...
      

The total byte count (or whatever it is) is now 0x8a97e. After this the caller must set the file time; otherwise it is left at -1.