Firmware 1.6 uses a new file format

[derickr]

The file format goes from "09" to "0A", which annoyingly changes some things in the TTBIN files that make ttbin/ttbincnv unable to parse the files.

I have discovered at least that this is changed in the header itself:

diff --git a/src/ttbin.c b/src/ttbin.c
index e554a16..16faca3 100755
--- a/src/ttbin.c
+++ b/src/ttbin.c
@@ -38,7 +38,7 @@ typedef struct __attribute__((packed))
 typedef struct __attribute__((packed))
 {
     uint16_t file_version;
-    uint8_t  firmware_version[3];
+    uint8_t  firmware_version[6];

There also seems to be a new tag in the file "0xFF" (position 0x1010C) which is not included in the tags-length structure and hence parsing fails through the condition:

343         /* find the length of this tag */                                                  
344         while ((index < file_header->length_count) && (file_header->lengths[index].tag != p.record->tag))
345             ++index;                                                                       
346         if ((index < file_header->length_count) && (file_header->lengths[index].tag == p.record->tag))
347             length = file_header->lengths[index].length;                                   
348         else
349         {                                                                                  
350             free_ttbin(file);
351             return 0;
352         }     

But I haven't managed to track down what to do with this. I've attached the new file as generated with the firmware - as you can see, the name of the file got mangled too (because of the header change).

new-firmware-file.zip

[mipapo]

Another testing file with the new firmware Running_06-48-37 (1).ttbin.zip

[mipapo]

The new tag could be the "Fitness points" (https://www.tomtom.com/en_gb/sports/fitness-age/#learnmore)

[derickr]

Sundays are fun for hacking on this stuff.

I figured out what it was. There is a new tag/lengts combination "K" that uses a length of FFFF, which does not mean a length of 65535, but instead a "variable" length, that is encoded right after the tag as a uint16_t:

000000D0 46 08 00 48 0F 00 49 05 00 4A 09 00 4B FF FF 48 F..H..I..J..K..H

(The following H is just a tag with data).

When the K tag is used with the FF FF value, the data looks like:

00000100                                             4B 18 00               K..
00000110   10 E3 BC 89  CE 05 18 A0  38 38 00 40  00 50 00 58  ........88.@.P.X
00000120   00 60 00 78  00 80 01 00                            .`.x....
00000120                             4A 67 5E C2  59 00 00 00          Jg^.Y...
00000130   00                                                 .

The K tag has a variable length of 0x0018 here.

I have a (slightly suboptimal) patch that can parse both version "09" and version "0A" now, but I have not tested writing in the few format yet. There is a PR at: https://github.com/ryanbinns/ttwatch/pull/134