FlySky i6 part 4: Custom updater

/!\ This updater is unstable, see there for the newer version /!\
Hi everyone! Today the train workers are in strike, so I can’t go to college, so I have plenty of time to release the product of my work!

But first thing first, a little bit of explanation. Today I’ll show you how the official FlySky updater works, and try to do mine!

Updater serial protocol

We know that the updater is using a serial com port to flash the firmware into the TX flash memory.
I used my logic analyzer to sniff the whole data transfer process, from this capture I understood how the protocol was working.

First thing it does is sending a « ping » request, wich is answered by the transmitter.

                    0    1     2    3    4    5     6    …                         …   n-1   n
[PC -> TX] 05  00  C0  3A  FF
[TX -> PC] 55  0F  00  C0  0A  00  01  00  00  00  00  00  00  D0  FE

Structure of the frame sent by the PC:

byte    function
1 0      size of the frame ( 2 bytes )
2         command type
…        parameters of the command, grouped by 2 bytes
n n-1  checksum (0xFFFF minus the sum of all the bytes of the frame) (2 bytes)

Frame sent by the TX: it’s the same principle, except that there’s an additionnal 0x55 byte at the begining of the frame.
I identified 4 types of commands:

C0: request name – no params
example: 05  00  C0  3A  FF
C1: restart TX – no params,[1 null byte]
example: 06  00  C1  00  38  FF
C2: ask to write bytes – location,[0x0900 ???],[8 null bytes]
example: 11  00  C2  00  18  00  09  00  00  00  00  00  00  00  00  0B  FF
C3: write bytes – location,[2 null bytes],data_block_size

The C2 command is sent before copying byte, to ask if we can send the next kB (1024 bytes) of data.
The TX replies with, following the same example than before:

55 13 00 C2 80 00 18 00 09 00 00 00 00 00 00 00 00 34 FE

The C3 command is the interesting one, it tells the TX to copy the bytes the PC is giving into its flash memory. It has a header with the C3 command, then the block of data bytes, then the checksum.

0B 01 C3 00 18 00 00 00 01 40 16 00 20 C5 19 … 18 47 B0 D7 00 00 85 C2
|————————————-|————————–…————————-|——–|
header                              data (256 bytes = 0x100 bytes)           checksum

The TX replies to every C3 command with:

55 0A 00 C3 00 00 00 00 DD FE

Custom updater

So I used all this information to code a custom updater wich follow the right updating process. My coding is not really clean, and it’s been a long time since I did C programming, but you can find it on github :

FSi6 updater on github OLD VERSION, don’t use it!!!

The new version of the updater is available. See this article for informations: BaseI6 Updater. You can download the tool on github >>> here <<< .

Final words

And most wanted: the release of my patch and the updater! I have done a lot of testing, I tried really hard to cause bricking of my device (including uploading a bad firmware made of random bytes), and I always was able to recover to the official firmware or directly to my firmware. So I think my updating method is pretty safe, as it doesn’t touch the bootloader section of the flash program.

But again, I’m not responsible for any harm you could do to your device! Please don’t blame me if something bad happens.

This patch allows the FS-i6 to use 2 additionnal channels. These channels are linked to the switches A and D and are only available through the iBus output of the iA6B receiver.

/!\ Someone with a TGY unit reported bricked device, don’t try it with the TGY units until I investigate further /!\

There is a way to recover the TGY device. The bricked TGY unit is now working, but the bug has also appeared on other TGY units. Maybe you need to update to the official FlySky 1.1 firmware before you use the custom updater.

Downloads:

BaseJ v0.1 patch and updater

Instructions are on the readme file.

PS: Help me to buy a new oscilloscope: Donate on PayPal !
Any help is really appreciated 😉