FlySky i6 part 2: A l’intérieur de la télécommande

Dans le précédent article, on avait remarqué qu’en plus d’envoyer au FC nos 6 canaux, le récepteur de la commande FS-i6 fournissait également 8 canaux supplémentaires. Il serait intéressant de pouvoir débloquer ces 8 canaux. Pour cela, la première chose à faire est de vérifier si ils sont bien transmis de la commande à son récepteur et non pas tout simplement créés de toute pièce par ce récepteur. Aujourd’hui on va donc mettre les mains dans le cambouis et sortir le tournevis de sa caisse!

Bon, ok, 4 vis c’est pas exceptionnellement difficile à démonter. L’intérieur est plutôt joli, le PCB semble de qualité. On reconnait un microcontrôleur (MCU) Freescale Kinetis L16 (MKL16Z64VLH4) au milieu. C’est un MCU basé sur une architecture ARM Cortex M0+, 32 bits. Un autre composant de taille est le module RF facilement reconnaissable à son capot métallique. Le dernier composant notable est à droite, la puce à 8 broches. C’est une puce de mémoire EEPROM de 128Kbits, c’est à dire de 16KBytes, notée 24C128, qui contient probablement les réglages de l’utilisateur.

image 2 IMG_1220

Le PCB est couvert de testpoints et son silkscreen est riche en informations! Il nous indique par exemple le port « Debug1 », qui est peuplé de son connecteur 4 broche, et l’utilité de ces broches: c’est une interface SWD (software debug) liée au MCU, qui peut être utilisée pour debuger mais aussi pour programmer la puce et peut-être même copier son firmware. Avoir autant d’informations servies sur un plateau d’argent, ça me fait presque penser que FlySky a envie qu’on bidouille sa commande, histoire de booster un peu les ventes en concurrençant la Turnigy 9x. Surtout que le MCU est dans sa version avec 64KB de mémoire flash, ce qui est la même quantité que le AtMega64 présent dans la 9x, et que donc un portage des custom firmware disponibles pour la 9x semble possible. Mais je m’égare 😉

En cherchant aux alentours du module RF, on retrouve, à sa gauche, 3 indications sur 3 testpoints:

  • SCS      (Chip Select, pour indiquer au module qu’on lui parle)
  • SCLK    (Clock, pour synchroniser la transmission)
  • SDIO    (Data In / Out, pour envoyer/recevoir les informations)

Ces 3 pins indiquent une interface de communication SPI, qui relie le MCU et le module RF. C’est un SPI un peu spécial, parce qu’il n’utilise que 3 fils, la transmission de données dans les 2 sens ne se faisant que sur un pin (SDIO). C’est un signal numérique: on ressort donc l’analyseur logique!

image 3

Transmission SPI

Etant donné que les données utilisent le même canal pour les 2 sens de communication, on ne pourra pas différencier directement qui envoie ou reçoit les données. Cependant, il s’agit d’un émetteur radio, le bon sens indique donc que la plupart des données ira du MCU au module RF. Il y aura pourtant bien de la communication dans l’autre sens: les données de télémétrie vont devoir être transmises du module RF au MCU.

Pour commencer, le récepteur n’est pas allumé, pour éviter de voir les informations de télémétrie qui reviennent au MCU. Voila un aperçu du bus sniffé:

without Rx

Le canal du haut est le SDIO, celui du bas le SCLK. Le SCS n’est pas sniffé, car peu intéressant. On voit qu’il y a la répétition, toutes les 3.8 ms, de 3 paquets de données. On peut utiliser le logiciel pour directement décoder les signaux en données hexadécimales (SPI, CPOL=0, CPHA=0, MSB first, 8bit).

Le premier paquet est constitué de 43 bytes, le second de 1 byte (0xD0) et le dernier de 4 bytes (0xF0 0x0F 0xXX 0xC0). Pourquoi avoir noté 0xXX ? Parce que ce byte contient la valeure 0x1C, mais cette valeur varie pour chaque frame. En fait elle parcourt une série prédéterminée de valeurs, mais ça sera expliqué plus loin.

Revenons au premier paquet de données, celui de 43 bytes, qui contiendra probablement nos 6 canaux. Si en plus des – canaux normaux, il contient lui aussi les 8 canaux supplémentaires, cela voudra dire que la télécommande transmet bien 14 canaux distinct au récepteur et que la limitation des 6 canaux est purement logicielle! (Le suspens est intenable, non?) Voyons donc un zoom sur le début et sur la fin de ce paquet, ainsi que son contenu:

without Rx zoom debut

without Rx zoom fin

xA0

xE0

x05x58
x5Ax89
x36x77
x41x88
xD0xB2
x5Cx05    chan 1
x17x06    chan 2
xF1x03    chan 3
xD1x04    chan 4
xD0x07    chan 5
xD0x07    chan 6
xDCx05    chan 7
xDCx05    chan 8
xDCx05    chan 9
xDCx05    chan 10
xDCx05    chan 11
xDCx05    chan 12
xDCx05    chan 13
xDCx85    chan 14
x00

x0F
xXX

On a donc de nouveau quelques byte en en-tête, leur contenu mériterait de s’y pencher plus tard, puis la présence de nos 14 canaux, tant attendus, et quelques bytes de clôture. Bonne nouvelle, les 14 canaux viennent bel et bien de la télécommande! Il n’y a donc aucune limitation technique à leur utilisation. (FlyFky aurait simplement bridé leur FS-i6 pour faire une différence entre plusieurs gammes d’appareils? Ils ne seraient pas les premiers!)

Le dernier byte du paquet (0xXX) est intéressant également, il contient la valeur 0x1D, et celle-ci varie également pour chaque frame, comme un des bytes du dernier paquet! Il varie selon l’ordre suivant:

… x60 x51 x1D x33 x16 x0F x64 x24 x7A x84 x59 x92 x68 x45 x6E x29 x60 x51 x1D x33 …

Et l’autre byte variable aura toujours la valeur de celui ci à laquelle on retire 1.
(en héxadécimal: 0x1D-0x01 = 0x1C)

Pistes d’avancement

Si on veut un jour utiliser ces canaux, je vois plusieurs solutions.

  1. Utiliser un autre microcontrôleur, pas besoin qu’il soit très compliqué, donc peut être peu cher. Cet autre microcontrôleur intercepterait la communication SPI  et la modifierai « à la volée » pour y modifier les valeurs des canaux supplémentaires, en fonction de switch connectés à ce microcontrôleur.
  2. Reprogrammer le MCU déjà présent, pour y ajouter le support des 14 canaux.

La première option a l’avantage de laisser la programmation du matériel « telle qu’elle » et donc de ne pas risquer de briquer le MCU (c’est à dire le rendre inutilisable par erreur de programmation, sans pouvoir meme reflasher son firmware). Cependant elle requiert du matériel supplémentaire, de programmer cette puce supplémentaire, de modifier le circuit existant pour y inclure la puce, et surtout de pratiquer cette interception et modification du SPI à la volée, sans introduire trop de latence! On ne veut pas que les canaux soient reçus trop tard par le quad n’est ce pas?

La deuxième a l’avantage d’être plus élégante. Le risque de briquer la puce peut éventuellement être levé en utilisant l’updateur officiel, modifié afin d’envoyer notre Custom Firmware fait maison. De plus, autre avantage non négligeable, il est envisageable de porter le code des custom firmware de la Turnigy 9x pour notre FS-i6. Ces firmwares sont déjà très aboutis et testés par beaucoup de monde. L’inconvénient majeur est de réussir à reprogrammer le MCU. En effet modifier l’updater officiel est loin d’être simple, et le matériel nécessaire à utiliser le fameux port « Debug1 » est relativement onéreux (et surtout je ne l’ai pas :p).

Dans le prochain article, on va cependant commencer à effectuer le Reverse Engineering de l’updater, et voir comment il programme la télécommande.

Thom

Advertisements

Une réflexion au sujet de « FlySky i6 part 2: A l’intérieur de la télécommande »

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s