Démontage d'un drone, Épisode 3 : La revanche de la télécommande.

Rédigé par Salamandar - - 6 commentaires

Le protocole de communication

Comme je l'avais dit au second épisode, j'ai besoin de comprendre le protocole de communication entre la télécommande et le drone. Comme c'est quasi impossible de souder des fils directement sur le drone, je vais écouter ce qu'il se passe sur la télécommande.

Sur la télécommande, un bus SPI communique entre la puce principale (un PIC ?) et le composant radio (probablement un XN297). J'ai utilisé un Arduino Nano pour écouter sur le bus et afficher en temps réel sur mon PC les trames SPI.

Plusieurs frames se répètent : les 4 premières correspondent à la configuration du XN297. Il m'a suffit de lire la datasheet du nRF24L01 pour connaître quelle configuration est envoyée.
La dernière frame contient les données à envoyer au drone. J'ai décortiqué cette dernière frame et j'ai indiqué quel octet correspond à quelle commande.

0x20 0x0e // Write byte config (Power up, CRC 1 byte enabled)
0x25 0x48 // Write byte RF_channel (freq channel : 100 1000 = chann 72)
0x27 0x70 // Write byte status (clear TX_status/RX_status/MAX_RT status bits)
0xe1 0x00 // Flush TX (clean and new TX buffer)
0xa0 0x55 0x3a 0x88 0x89 0x8a 0xdc 0x05 0xdc 0x05 0xe8 0x03 0xdc 0x05 0x00 0x00
// Write TX buffer data

// Data frame :
//                   Côté  av/ar Gaz   Rotat
// A0 55 3A 88 89 8A cc cc aa 0a gg 0g rr Xr XX X0
// 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
// byte 14 : 1000 .... Looping
// byte 15 : .1.. .... (press repeat) calibration B (btn2)
// byte 15 : ..1. .... (press repeat) calibration F (btn1)
// byte 15 : ...1 .... (press repeat) calibration L (btn3)
// byte 15 : .... 1... (press repeat) calibration R (btn4)
// byte 15 : .... ..xx Difficulté (0, 1, 2)
// byte 16 : .100 0000 (toggle button) photo
// byte 16 : 1.00 0000 (toggle button) video

J'ai donc ici l'intégralité du protocole de communication. Le drone ne répond jamais, c'est plus simple comme ça.

Prochaine étape : programmer le drone !

Démontage d'un drone, Épisode 2 : Un peu d'électronique

Rédigé par Salamandar - - Aucun commentaire

La prise de vidéo

Dans notre premier épisode, on a vu l'existence d'un fil de signal pour la prise de photos. Ce signal est maintenu par le STm32 en permanence à ~3V (1 logique, donc), et une photo est demandée par une courte mise à zéro (entre 230 et 320ms), et la vidéo par une plus longue (610~710ms).
Eh oui, j'ai accès à un simple oscilloscope analogique, alors si vous voulez des mesures plus précises, offrez-moi un oscilloscope numérique ;)
N'ayant aucune information sur le SoC vidéo, c'est la seule information que je peux avoir.

L'électronique

Toute première étape, établir un schéma de fonctionnement du drone. Autrement dit, comprendre comment les différents composants sont connectés entre eux pour savoir, ensuite, quel code écrire.

On m'a donné la bonne idée d'utiliser Gimp pour superposer des photos des deux couches du PCB, et dessiner les vias et les pistes, histoire de s'y retrouver facilement. À côté, j'utilise Kicad pour représenter le PCB.

J'ai uniquement représenté les trois composants principaux : le STm32, le contrôleur radio, et la centrale inertielle. On arrive donc à un schéma assez simple.
La centrale inertielle Invensense comunique vraisemblablement en I2C avec le STM32. Pour le contrôleur radio, ça sera du SPI.
Vous pouvez tout trouver sur mon dépôt Github.

Les 3 "pads" que j'ai notés A,B,C sur la photo ci-dessus sont directement connectés au STm32, sur les pins permettant de le reprogrammer, en passant par le Serial Wire du JTAG :

  • PA13 = SWDIO (Serial Wire Debug I/O)
  • PA14 = SWDCLK (Serial Wire Debug Clock)
  • VDD : L'alimentation, simplement 

J'ai donc soudé un header de 4 pins sur ces pads, de façon plus ou moins crade, en le collant à l'époxy pour ne pas risquer d'arracher les pistes dessus en le (dé)branchant (ce qui a déjà commencé à arriver…).

Un peu de logiciel

Pour accéder au Serial Wire du STm32 depuis mon PC en USB, j'ai besoin d'un ST-Link. Et justement, les Nucleo de STMicroelectronics en embarquent un pour programmer leur STm32, et la possibilité a été laissée d'utiliser le ST-Link pour programmer d'autres STm32.
Parfait donc ! J'utilise aussi l'alimentation de la Nucleo pour ne pas tirer inutilement sur la batterie.

J'utilise OpenOCD pour communiquer avec le ST-Link.

$ sudo openocd -f /usr/share/openocd/scripts/board/st_nucleo_f0.cfg &
Open On-Chip Debugger 0.10.0-dev-00419-gbcaf775 (2016-11-07-18:43)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control.
       The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v25 API v2 SWIM v14 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.250952

$ telnet localhost 4444
Trying ::1...
Connection failed: Connexion refusée
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Info : accepting 'telnet' connection on tcp/4444
Open On-Chip Debugger
> init
> flash probe 0
# Pour avoir quelques infos sur le microcontrôleur
Info : device id = 0x10006444
device id = 0x10006444
Info : flash size = 16kbytes
flash size = 16kbytesflash 'stm32f1x' found at 0x08000000
flash 'stm32f1x' found at 0x08000000
> dump_image drone.bin 0x08000000 0x20000
# Pour tenter de récupérer le firmware actuel.
# Résultat : drone.bin est vide !
>

Je détecte bien le STm32F0 ! Bon, c'est plutôt un stm32f1 qui est détecté, mais on s'en suffira. Par contre, aucun moyen de sauvegarder le firmware actuel : ils ont activé les protections du Stm32.

Dommage, ça veut dire qu'une fois le drone bidouillé, je ne pourrai pas revenir en arrière !

Les étapes suivantes ?

  • Lire la datasheet du transceiver radio XN279, ou plutôt, vu que celle-là est en chinois, celle du nRF24L01+.
  • Tenter de "lire" les paramètres radio envoyés par le STM32 au transceiver, si je n'ai pas réussi à les deviner (ce qui est probable), ainsi que le "protocole" utilisé entre la télécommande et le drone. Pour ça, il va falloir utiliser utiliser un analyseur logique.
  • Pour l'accéléromètre ça sera plus simple, il suffira de lire la doc', je verrai donc une fois que la radio fonctionne.

Démontage d'un drone, Épisode 1 : Le contenu.

Rédigé par Salamandar - - 1 commentaire

J'ai récemment fait l'heureuse acquisition d'un nano-drone (35mm d'axe à axe !) avec caméra intégrée. Le genre chinois sans marque, et ça se voit jusqu'aux composants. Du coup, je me suis lancé le défi de le démonter, le comprendre et le reprogrammer. Un vrai boulot de hacker :)

L'intérieur est composé de deux PCBs :

  • Une première carte, qui fait aussi office de squelette physique du drone.
    • Un STm32f031K4, basé sur un petit core ARM-M0 cadencé à 48MHz. Un tout petit cerveau mais largement suffisant, quoi.
    • Un Invensense MPU-6052C, qui contient un gyroscope et un accéléromètre. Je trouvais le drone assez mal stabilisé, on va changer ça !
      D'ailleurs, les seules infos que j'ai trouvées sur le net sur ce composant sont dans une datasheet "préliminaire et confidentielle"… À part ça, il n'est commercialisé nulle part et aucune datasheet "publique" n'est trouvable. Ça commence bien… !
    • Un Panchip XN297, qui gère la communication sans fil. Il a l'air assez commun, et même un clone des Beken BK2425 et nRF24L01+. Même si la seule datasheet que j'ai trouvée est en… Chinois :)
  • Une seconde carte, plus petite, gère la partie vidéo.
    • Un BoyaMic 25Q40A gère vraisemblablement la partie enregistrement sur la carte microSD. Funny fact, d'autres drones sont équipés d'une puce semblable "BergMic 25Q40A". Sérieux, les gars ? Vous avez monté une boîte avec un nom ressemblant à celui d'origine ?
    • Un SoC, assez épais, avec un très joli logo, mais totalement inconnu par moi et par Internet. Et le "BD8A534" est tout simplement inexistant. Bon, c'est clair, il gère la compression vidéo depuis la caméra.

    En fait, je me fous assez de la deuxième carte : les deux cartes ne sont reliées que par trois fils (W/R/B donc Masse/Puissance/Signal), le fil de signal doit simplement déclencher la prise de photo/vidéo. Il suffira de comprendre ce signal.

C'est tout pour cette fois, la suite au prochain épisode !

Fil RSS des articles de ce mot clé