Genèse de cet article
Cet article vient en complément de l’article précédent : Dé-bricker une clé RTL-SDR. Je vous recommande ainsi vivement sa lecture, il fixe le contexte de celui-ci.
Je vais ainsi détailler dans cet article le cheminement que j’ai suivi pour résoudre cette panne en détaillant chaque étape, chaque échec, chaque avancée.
Cet article me sert également de mémento avec la liste des outils utilisés, programmes …
Contexte : Déclaration de la panne
Lors de l’utilisation de la clé je remarque que dans le bandeau de démarrage de rtl-sdr (rtl_test, rtl_fm, rtl_eeprom…) le nom affiché ne correspond pas exactement à ce que j’avais précédemment défini dans l’EEPROM plus d’un an plus tôt. Il y a un problème, peu grave et simplement esthétique visiblement. Ça me perturbe suffisamment pour me tenter de réécrire l’EEPROM afin de corriger ce problème. Lourde erreur.
J’aurais bien aimé pouvoir illustrer cela, cependant je ne m’attendais pas à devoir dépanner ma clé qui ne répondait plus 30 secondes plus tard …
J’exécute donc la commande suivant visant à modifier le nom de la clé RTL-SDR :
rtl_eeprom -d 0 -p "RTL-SDR of F4IIL"
Lors du résumé précédent la réécrite le soft nous présente la configuration actuelle et la future configuration. La configuration actuelle est bien complètement buguée mais la future est correcte. Je valide la réécriture. Aucune erreur n’apparaît et le soft me confirme que tout s’est bien passé, au rebranchement de la clé les changements devraient apparaître.
Passé cet instant la clé ne sera désormais plus reconnue par rtl-sdr sous linux. Sous Windows Zadig la reconnaîtra mais malgré plusieurs tentatives de réinstallation des drivers SDR# ne reconnaît plus la clé.
C’est le « drame ».
Première étape : Identifier l’EEPROM
Au vu du déroulé des évènements, il ne serait pas choquant que la réécriture de l’EEPROM effectuée précédemment soit à l’origine du problème (l’inverse serait choquant même …).
Je commence d’abord par inspecter le PCB de la clé RTL-SDR. Se dégage de ce circuit trois boitiers dont deux ayant une fonction purement RF. Le troisième à contrario après quelques recherches s’avère être une EEPROM : parfait, c’est ce que je cherche !
Le boitier de l’EEPROM est un SO-8, soit le seul boitier du circuit qui est facile à extraire sans trop de matériel.

Le schematic des clé RTL-SDR est trouvable en quelques clics sur internet et après passage sous la caméra loupe je confirme bien la référence de l’EEPROM : 24C02.
En poursuivant mes recherches, je trouve deux datasheet correspondant à la référence du composant : le premier de chez STMicroelectronics et le second de chez Microchip. La comparaison entre l’observation du circuit et le pinout décrit par le datasheet correspond.
Il s’agit donc d’une EEPROM de 2Kbits et fonctionnant grâce au bus
I2C. Ce type de mémoire étant assez répandu, il ne devrait pas être trop
dur de trouver des programmes Arduino déjà existant qui l’utilise.
Seconde étape : Lecture de l’EEPROM
Je trouve rapidement ce programme permettant la lecture et écriture d’EEPROM similaires grâce à une carte Arduino. (Internet est quand même un outil formidable quand on y pense. Comment s’en passer de nos jours ? Fin de parenthèse philosophique).
Je m’empresse d’extraire l’EEPROM et de la connecter à une carte Arduino trouvée au fond du tiroir à côté du bureau.
Je modifie le programme afin qu’il affiche dans le moniteur série un dump de la mémoire au format hexadécimal.
Le résultat obtenu ? Un bloc de 0xFF … J’ai donc deux possibilités, soit l’EEPROM a été complètement formatée avec des 1 de partout lors de l’utilisation de rtl_eeprom, soit le programme ne fonctionne pas.

Je modifie donc la ligne suivante avec une autre valeur :
byte rdata = 0x26; //0xFF par défaut
Compilation, téléversement … Paf un bloc de 0x26 …
Le programme a donc bien un problème. L’utilisation d’un scanner I2C écartera la possibilité d’une défaillance dans la communication avec la mémoire : la mémoire est reconnue et répond bien à l’adresse 0x50.
Après analyse du programme et des datasheet, j’en déduis que l’adresse des octets du programme exemple est codée sur 16 bits là où la mémoire de la clé RTL-SDR n’est codée que sur 8 bits. Modification du programme faite, la lecture et l’écriture de la mémoire fonctionne désormais.
Dans un premier temps pour analyser ce dump avec un interpréteur ASCII, je copie colle le contenu du moniteur série dans un fichier dump.hex. J’utilise ensuite la commande xxd afin de le transformer en fichier binaire me permettant d’utiliser hexdump pour l’analyser :
xxd -rp dump.hex dump.bin hexdump -Cv dump.bin
On peut d’ailleurs simplifier ceci de la manière suivant, le résultat est identique :
xxd -rp dump.hex | xxd -
Ici c’est clairement du bricolage mais ça fonctionne donc … Je modifie juste après le programme afin qu’il effectue directement l’hexdump dans le moniteur série.
Troisième étape : Récupération d’un dump vierge
Et c’est à cet instant que je découvre que rtl_eeprom permet de réécrire l’EEPROM d’usine pour les clé RTL-SDR. Je tente alors de modifier le fichier source rtl_eeprom.c en le dissociant de la lib rtl-sdr. Un fois distinct, je peux le recompiler facilement avec gcc. Je le modifie pour qu’il m’affiche le contenu d’un dump vierge comme si on exécutait :
rtl_eeprom -g realtek_oem
Après ça, un peu de python pour mettre en forme le résultat obtenu et pouvoir l’insérer dans le programme Arduino. J’écris l’EEPROM avec ce dump. Je la ressoude temporairement à sa place : les pins 1 à 4 sont soudés ensemble avec un fil et relié à la masse, les 4 autres sont soudés sur leurs pastilles d’origine. Le laisser à moitié volant permet de le redessouder facilement au besoin (besoin il y aura).
Après avoir connecté la clé une première fois, j’ai des erreurs.
Après l’avoir connecté une seconde fois il m’indique se remettre à zéro, soit.
Après l’avoir connecté une troisième fois, ça marche !
Ça marche mais elle fonctionne sans EEPROM … Après avoir dessoudé l’EEPROM de nouveau, j’observe le même fonctionnement. Ceci donnera donc lieu à la première méthode de réparation dans le premier article. Cependant ceci pose quelques problèmes comme l’impossibilité de l’utiliser avec d’autres clés notamment.

J’aurais à ce moment voulu obtenir d’un autre possesseur de ce modèle
de clé un dump vierge mais étant trop impatient je décide de tester une
autre méthode : reflasher le dump à moitié corrompu que j’avais
soigneusement sauvegardé avant de vouloir remodifier le nom du produit
comme indiqué au début de cet article.
Second essai, ça refonctionne comme avant donc j’ai enfin fait un
retour à la case départ. Je procède ensuite au reflashage par défaut de
l’EEPROM grâce à l’option -g de rtl_eeprom. Voici ma clé RTL-SDR comme neuve !
Suite à cela j’enregistrerai un dump vierge qui m’a servi à insérer dans l’article précédent.
Conclusion
- Coût : absolument rien, pas besoin d’acheter une nouvelle clé, un programmateur d’EEPROM plus ou moins cher ou d’autres composants
- Durée : un peu plus de 2h30
- Utilitaires utilisés : lib rtl-sdr, hexdump, xxd, gcc, python3 et Arduino
- Matériel : Arduino UNO, 2 résistances, 3 fils et … c’est tout !
Ressources complémentaires :
- Schematic clé RTL-SDR
- Datasheet 24C02 : STMicroelectronics / Microchip
- Scanner I2C
- Lecture/écriture EEPROM I2C Arduino
- Sources lib rtl-sdr
- Sources et fichiers binaires liés à cet article
- Thread raccourci temps réel de cet article : sur Twitter








