SE4 2024/2025 EC3

Objectifs

Vous allez concevoir, réaliser et programmer un système embarqué de remise à zéro d'équipements réseau.

Les équipement réseau visés sont des éléments Cisco. Pour remettre à zéro un élément réseau Cisco, il faut passer en mode administrateur et envoyer la commande erase startup-config. Ensuite si l'équipement est un commutateur il faut effacer la liste des VLAN avec la commande del vlan.dat. Si l'équipement est un point d'accès WiFi il faut supprimer l'adresse IP sur l'interface BVI1.

L'épreuve complémentaire sera considérée comme un succès si votre système embarqué arrive à réinitialiser un ISR4221, un Aironet 1600 et un C9200.

Vous commencerez par concevoir votre carte dont le coeur doit être un microcontrôleur AVR et qui doit pouvoir converser avec un périphérique série (que ce soit via USB ou en utilisant un port RJ45). L'utilisateur doit aussi pouvoir relancer la mise à zéro via un bouton et connaitre l'état de la mise à zéro via des LED. Une réflexion doit être menée sur l'alimentation de la carte. Vous avez le droit à un budget de 50 euros pour la carte, les composants et le port.

Une fois la carte conçue et validée par l'encadrant vous pourrez vous pencher sur la programmation de la carte. Cette programmation se fera uniquement en utilisant la version AVR de gcc et l'utilitaire dfu-programmer.

Il s'agit là d'un cahier des charges initial qui peut être revu en cas d'ambigüité. Vous avez jusqu'au 1 septembre pour réaliser le travail demandé. Il vous est explicitement demandé de produire un travail régulier le plus tôt possible *et* de faire des rapports réguliers (obligatoirement au travers de ce Wiki) à votre encadrant. S'y prendre à la dernière minute avec un seul retour à quelques jours de la date limite est une garantie d'échec.

Développement et tests

Pour vous rappeler les commandes IOS Cisco vous pouver utiliser un logiciel de simulation d'éléments réseau comme Packet Tracer.

Ensuite pour tester l'algorithme haut niveau de votre programme embarqué vous pouvez :

• écrire un programme C simulant les quelques commandes IOS Cisco nécessaires pour la remise à zéro ;
• attacher ce programme sur un port série virtuel avec l'utilitaire socat ;
• écrire un programme C classique qui se connecte au port série virtuel, qui communique avec le "périphérique" pour connaître son type et envoyer les ordres nécessaires pour la remise à zéro.

Pour la suite vous écrirez le vrai programme embarqué en intégrant votre algorithme haut-niveau dans le projet LUFA adapté.

Pour tester le programme sur votre carte vous pouvez la connecter à un Arduino Uno programmé pour simuler les quelques commandes Cisco nécessaire pour la remise à zéro.

Enfin vous testerez votre carte en situation reelle sur les équipements Cisco fin août.

Travail réalisé

Avancement du 18/07

Schématique terminé

J'ai finalisé aujourd'hui une première version du schéma électronique de ma carte à base d'ATmega328P-A (boîtier TQFP-32). Tous les éléments essentiels ont été intégrés, en respectant les contraintes du cahier des charges.

Choix de l'alimentation via USB micro-B

Pour l'alimentation de la carte, j'ai opté pour un connecteur micro-USB type B, utilisé uniquement pour fournir du +5V et GND à la carte. Le 5V est ensuite filtré à l'aide d'un condensateur de 10 µF en entrée, et des condensateurs de découplage (100 nF) sont placés près du microcontrôleur pour stabiliser la tension localement.

LED de signalement d'état

J'ai intégré trois LED sur la carte pour signaler visuellement les états du système :

• LED Témoin : Mise sous tension (Power ON)
• LED_JAUNE : Remise à zéro en cours
• LED_VERTE : Remise à zéro terminée avec succès
• LED_ROUGE : Remise à zéro terminée sans succès

Chaque LED est reliée à une broche du microcontrôleur à travers une résistance de limitation de courant.

Communication série avec les équipements Cisco

J'ai choisi d'utiliser un adaptateur FT232RL (module USB ↔ UART TTL) pour assurer la communication entre ma carte et les équipements Cisco à réinitialiser. Le module FTDI sera connecté à un header 2x3 broches (J4) sur la carte (signaux TX, RX, GND, VCC), et une liaison physique sera assurée vers le port console RJ45 des équipements via un câble série.

Avancement du 19/07

Aujourd'hui, des choix techniques importants ont été faits suite au retour de M. REDON, concernant la première version du schéma électronique, pour assurer la compatibilité complète de ma carte avec tous les équipements Cisco visés (Aironet 1600, ISR4221, C9200).

Changement du microcontrôleur

J'ai remplacé le ATmega328P-A initialement utilisé, par un ATmega16U4-A (boîtier CMS TQFP-32). Ce dernier microcontrôleur possède une interface USB native, indispensable pour communiquer directement avec le Cisco C9200, qui ne dispose que d'un port USB console.

Présence de 3 boutons poussoirs

Trois boutons distincts sont intégrés au schéma :

• Bouton RESET : connecté à la broche RESET du microcontrôleur. Il permet de redémarrer le programme en cours.
• Bouton HWB : connecté à la broche HWB du microcontrôleur. Lorsqu'il est maintenu appuyé au moment d’un RESET, il permet de démarrer le microcontrôleur en mode bootloader DFU, pour reprogrammer le firmware via USB.
• Bouton de remise à zéro des équipements Cisco : connecté à la broche PD5. C’est l'utilisateur qui l’actionne pour déclencher, via le firmware LUFA, l'envoi des commandes nécessaires à la remise à zéro de l’équipement cisco.

Connexions USB

Un connecteur USB micro-B est utilisé pour :

• Alimenter la carte (5V via VBUS)
• Communiquer avec les équipements cisco (C9200 ici) via l’interface USB native

Connexions série UART

Un connecteur 2x3 broches est conservé pour accéder aux lignes TX/RX/GND/VCC. Il servira à communiquer avec les équipements Cisco disposant d’un port console série RJ45, comme les ISR4221 et Aironet 1600.

Avancement du 22/07

Remplacement du microcontrôleur ATmega16U4-A par un AT90USB1287, afin de rendre ma carte capable de fonctionner comme un hôte USB (USB Host). Ce changement est essentiel pour pouvoir communiquer avec des équipements Cisco comme le C9200, qui n'ont qu'un port USB console.

J’ai compris que les microcontrôleurs comme le 16U4 ne peuvent agir que comme périphériques USB (USB Device), alors que le 1287 est capable d'agir comme un contrôleur USB (USB Host), ce qui est requis par le projet. Ce choix me permet d'utiliser directement la démonstration LUFA Host/ClassDriver/VirtualSerialHost.

La carte est désormais conçue pour être alimentée et programmée par un seul port USB (mâle), et elle pourra ensuite communiquer avec un équipement réseau via un second port USB (femelle), en mode hôte.

Avancement du 29/07

Ajout d'un 2e bouton utilisateur sur la carte et remplacement du connecteur 2x3 par un RJ45 (dont la référence utilisée pour le brochage est présente ci-dessous).

Brochage RJ45

Modification de la première version du routage pour prendre en compte les ajouts mentionnés ci-dessus et pour également réduire le nombre de vias et mieux placer les condensateurs du quartz comme indiqué par monsieur REDON.

Avancement du schéma KiCad – 09/08/2025

1. Correction du câblage RJ45

• Modification du brochage conformément au retour encadrant :
  • Broches 4 et 5 reliées au GND.
  • Broche 3 du RJ45 → reliée au RX du µC.
  • Broche 6 du RJ45 → reliée au TX du µC.
• Ajout de deux connecteurs 3 broches (type jumper/cavalier) pour inverser TX/RX selon le type de câble (droit ou croisé).
  • Position normale : Broche 3 RJ45 → RX µC et Broche 6 RJ45 → TX µC.
  • Position inversée : Broche 3 RJ45 → TX µC et Broche 6 RJ45 → RX µC.
  • Permet d’assurer la compatibilité avec câbles droits et croisés sans modification logicielle.

2. Résistances sur lignes USB (D+ et D−)

• Ajout de résistances série 22 Ω sur D+ et D−.
  • Placées au plus près des broches USB du AT90USB1287.
  • Concernent à la fois le port USB Device (USB A mâle pour DFU) et le port USB Host (USB A femelle pour contrôle Cisco).

3. Condensateurs de découplage

• Correction du placement : les condensateurs sont désormais placés entre chaque broche VCC/AVCC/UVCC du µC et GND (et non entre VCC et +5V).
  • Un condensateur de 100 nF céramique par broche d’alimentation.
  • Placés au plus près des broches d’alimentation du microcontrôleur.
• Maintien d’un condensateur électrolytique de 10 µF sur la ligne d’alimentation générale pour la stabilité.

Documents Rendus

Projet KiCAD de la carte

Vous pouvez trouver ci dessous la première version du schéma électronique de ma carte réalisée le 18/07.

schematique (première version)

vous pouvez trouver ci-dessous la seconde version du schéma électronique de ma carte realisée le 19/07.

schematique (seconde version)

vous pouvez trouver ci-dessous la troisième version du schéma électronique de ma carte (avec un at90usb1287) réalisée le 20/07.

schematique (troisième version)

vous pouvez trouver ci-dessous la quatrième version du schéma électronique de ma carte réalisée le 22/07.

schematique (4e version)

vous pouvez trouver ci-dessous la 5e version du schéma électronique de ma carte réalisée le 24/07 ainsi que la 1ere version du routage.

schematique (5e version)

PCB 1ère version

vous pouvez trouver ci-dessous la 6e version du schéma électronique de ma carte réalisée le 29/07

schematique (6e version)

PCB 2e version

vous pouvez trouver ci-dessous la 7e version du schéma électronique de ma carte réalisée le 9/08

schematique (7e version)

Commandes Cisco

Listez les commandes Cisco nécessaires pour la remise à zéro des équipements visés.

Programme de simulation d'IOS Cisco

Joindre l'archive du programme C (avec Makefile) permettant de simuler les ordres Cisco permettant la remise à zéro.

Simulation logicielle du protocole de remise à zéro

En attendant de recevoir la carte électronique, une étape de simulation a été réalisée afin de valider l’algorithme haut niveau de remise à zéro des équipements Cisco.

Objectif

• Simuler le dialogue série entre la carte de contrôle (host) et un équipement Cisco (device).
• Tester les séquences de commandes nécessaires à l’effacement de la NVRAM et au redémarrage.
• Vérifier la bonne détection du modèle d’équipement et l’application des bons profils de temps (appui long sur reset).

Mise en place

• Deux programmes C ont été développés :
  • sim_ios : émule un périphérique Cisco en répondant à un sous-ensemble de commandes IOS.
  • host_ctrl : implémente l’algorithme haut niveau qui sera intégré plus tard sur l’AT90USB1287.
• Une paire de ports série virtuels est créée avec l’outil socat grâce à la commande  :

 # socat -d -d pty,raw,echo=0,link=/tmp/ttyHOST pty,raw,echo=0,link=/tmp/ttyDEV

• Le simulateur est lancé sur /tmp/ttyDEV et le contrôleur sur /tmp/ttyHOST.

Commandes simulées

Le simulateur comprend les commandes suivantes :

• help : liste les commandes supportées.
• ID? : renvoie l’identifiant du modèle (ex. ISR4221, Aironet1600, C9200).
• show version : affiche une version simplifiée de l’équipement.
• write erase / erase nvram : efface la NVRAM.
• reload / reset : simule un redémarrage de l’équipement.

Profils de reset

Trois profils de temporisation sont définis, en fonction du modèle détecté :

• ISR4221 : appui 8 s, relâchement 0,5 s, délai post-reset 3 s.
• Aironet1600 : appui 10 s, relâchement 0,5 s, délai post-reset 5 s.
• C9200 : appui 12 s, relâchement 0,5 s, délai post-reset 5 s.

Fonctionnement observé

• Au lancement, le host lit la bannière du simulateur.
• Il envoie ID? et identifie correctement le modèle simulé.
• Il applique ensuite la séquence :

 # envoi de write erase, réception de Erasing NVRAM...done;
 # maintien simulé du bouton reset pendant la durée définie par le profil ;
 # envoi de reset (ou reload), réception de Reloading... puis OK.

• Le host affiche dans son terminal les lignes reçues avec l’indicateur [RX] ainsi que les étapes de la séquence.

Exemple de session

[RX] Cisco IOS XE Software, Version 17.3.1

[RX] Device: Aironet1600

[RX] Type 'help' for cmds

[INFO] Detected device: Aironet1600 -> profile press=10000ms

[RX] Erasing NVRAM...done

[ACT] Holding reset (sim) for 10000 ms...

[RX] Reloading...

[RX] OK

[OK] Reset sequence completed. Post-wait 5000 ms

Conclusion

Cette simulation valide :

• la communication série host ↔ périphérique,
• la détection automatique du modèle d’équipement,
• l’application des séquences de reset adaptées.

Programme préliminaire de remise à zéro

Joindre l'archive du programme C (avec Makefile).

Programme embarqué LUFA

Archive attachée avec Makefile intégré.

Vidéos de démonstration.

Programme Arduino Uno

Programme simulant un élément Cisco avec un Arduino Uno.