Horloges temps réel (RTC) des microcontrôleurs : Conception, précision et sécurité

Partie 3 de la série Timers Microcontrôleurs : À l'intérieur des Horloges Temps Réel (RTC)

Dans cet article, nous plongeons au cœur des horloges temps réel (RTC) basées sur microcontrôleurs. Les articles précédents couvraient les fondamentaux des timers et la modulation de largeur d'impulsion. Cet article explique comment les RTC maintiennent des intervalles précis d'une seconde, gèrent l'heure et la date, compensent la dérive, et se protègent contre la falsification.

Ce que fait une RTC

Les RTC sont du matériel dédié qui génère une impulsion stable d'une seconde et maintient un comptage continu. Un diagramme de temporisation simple montre le générateur d'impulsions, une routine logicielle qui lit le compteur de secondes, et une alarme qui se déclenche trois secondes plus tard. Les exigences clés sont la précision et le fonctionnement continu.

Figure 1. Diagramme de temporisation RTC de base

Caractéristiques matérielles typiques

Les RTC de microcontrôleurs modernes incluent généralement :

• un oscillateur interne 32 768 Hz (souvent avec option quartz ou TCXO)
• une entrée d'horloge externe pouvant fournir une référence hautement précise
• un multiplexeur pour sélectionner la source, suivi d'un prédiviseur qui divise par 32 768 (2¹⁵) pour générer l'impulsion 1 Hz
• un compteur de secondes 32 bits (ou plus), et compteurs optionnels pour minutes, heures, jours, mois, et années
• une sortie d'onde carrée 1 Hz
• des broches d'interruption pour alarmes, impulsions de secondes, ou autres événements
• une broche d'alimentation de secours dédiée, généralement une pile bouton, pour que l'horloge continue de tourner quand le reste de la puce est hors tension

Figure 2. Caractéristiques matérielles courantes des RTC

Précision et compensation de fréquence

Le cœur d'une RTC est son quartz 32 768 Hz. Dans un oscillateur bien conçu, le quartz lui-même est la principale source d'erreur. Les TCXO externes peuvent délivrer une stabilité sous-ppm, tandis que les oscillateurs internes peuvent être compensés pour atteindre une performance comparable.

Sources d'erreur typiques incluent :

• tolérance initiale du quartz et du circuit environnant
• dérive thermique, qui suit une courbe quadratique prévisible
• vieillissement, généralement seulement quelques ppm par an

Le graphique ci-dessous, courtoisie de Texas Instruments, illustre comment la température et l'erreur initiale se combinent, et comment un calibrage soigneux peut amener l'erreur totale dans la bande jaune — une cible atteignable après mesure au niveau carte.

Figure 3. Erreur vs température (Texas Instruments)

Avec une précision de 1 ppm sur un an, l'horloge dévie d'environ 30 secondes — bien mieux que la plupart des projets amateurs mais qui vaut encore la peine d'être prise en compte dans les systèmes critiques.

Compensation des erreurs de temporisation

Deux stratégies courantes existent pour corriger la dérive mineure sans sacrifier la simplicité du matériel :

Prédiviseur ajustable. Si la RTC expose un prédiviseur programmable, le logiciel peut ajuster le modulus toutes les quelques secondes. Par exemple, une horloge qui avance de 0,00010 s peut changer le prédiviseur de 32 768 à 32 781 une fois toutes les quatre secondes, ajoutant les 0,00010 s manquants chaque fois.

Figure 4. Ajustement du prédiviseur pour contrer la dérive

Avantages : corrections fines et code minimal. Inconvénient : nécessite un prédiviseur ajustable et registres supplémentaires.

Correction logicielle. Quand le matériel manque de prédiviseur programmable, le firmware peut tenir un décompte courant du compteur de secondes. Quand l'erreur accumulée atteint une seconde, il ajoute ou soustrait une impulsion. L'ajustement n'est visible qu'une fois par cycle, ce qui peut sembler brutal.

Figure 5. Correction de temporisation logicielle uniquement

Avantage : fonctionne avec toute RTC. Inconvénient : sauts notables dans le taux d'impulsions.

Considérations de sécurité

Dans les applications où le temps est lié à la facturation, limites d'usage, ou séquençage critique, protéger la RTC contre la falsification est essentiel. De nombreux microcontrôleurs fournissent :

• des registres protégés en écriture qui peuvent être verrouillés définitivement par logiciel
• des exigences de réinitialisation matérielle pour modifier l'heure (une réinitialisation complète efface le verrou)
• une détection d'intrusion au niveau du boîtier pour alerter sur la falsification physique

Par exemple, le MCU utilisé dans cet article a un bit de verrou qui, une fois défini, ne peut être effacé qu'après réinitialisation de la puce, empêchant le code malveillant d'altérer l'horloge.

Gestion de l'heure et de la date

Certaines RTC intègrent des compteurs complets d'heure du jour et de calendrier. Si le matériel les manque, le firmware peut dériver la date du compteur de secondes 32 bits en utilisant des algorithmes standards. La bibliothèque C standard time.h attend une fonction qui retourne les secondes depuis l'époque (généralement 1 jan 1970). Un simple wrapper get_time() qui lit le compteur de la RTC alimente la bibliothèque, qui gère alors années bissextiles, heure d'été, et formatage.

Limites des compteurs de secondes 32 bits

Un compteur 32 bits débordera après 2³² secondes — un peu plus de 136 ans. Cependant, quand l'époque commence en 1970, le compteur roulera en 2038 (le problème Y2038). Les systèmes s'appuyant sur la bibliothèque C peuvent subir un comportement indéfini quand le compteur atteint 2³¹ – 1.

La mission Deep Impact de la NASA a perdu la communication en 2013 après qu'un timer 32 bits suivant le temps en incréments de 0,1 seconde ait débordé, potentiellement corrompant les commandes de contrôle.

« Bien que la cause exacte de la perte ne soit pas connue, l'analyse a découvert un problème potentiel avec l'étiquetage temporel informatique qui aurait pu mener à la perte de contrôle de l'orientation de Deep Impact. »

— Communiqué NASA, 2013

Les concepteurs devraient utiliser des compteurs dépassant confortablement la durée de vie attendue du système, ou implémenter la gestion du débordement dans le firmware.

Prochaines étapes

L'article final de cette série couvrira les watchdog timers, le filet de sécurité qui maintient un microcontrôleur en vie même quand le logiciel plante.