Échec de la communication série du MSP430 par temps froid

8

J'ai un produit utilisant le microprocesseur MSP430, qui se vend depuis quelques années maintenant. L'une des tâches du MSP430 est de communiquer via une série asynchrone avec une radio de faible puissance.

Avec le début de cet hiver, il y a eu un taux d'échec inacceptable (plusieurs pour cent) à froid. L'enquête a révélé que la communication série avec la radio échoue. Le générateur de vitesse de transmission pour le port série est alimenté par SMCLK, qui est divisé à partir de l'oscillateur à commande numérique (DCO) du MSP430.

Pourquoi la communication série échoue-t-elle à basse température?

(Remarque: j'ai déjà résolu le problème et je publierai bientôt la réponse. Astuce: il s'agissait d'un bogue logiciel.)

markrages
la source

Réponses:

8

Quel MSP430 utilisez-vous? Les différentes familles ont des structures d'horloge et des capacités différentes.

Le DCO changera de fréquence avec la température, ce qui entraînera une dérive du débit en bauds USART hors spécifications. Le MSP dispose d'un capteur de température (peu précis). Vous pouvez modifier les valeurs dans les registres de contrôle DCO pour ramener la fréquence DCO dans la plage, mais cela nécessiterait des tables de recherche calibrées couvrant la plage de températures que vous attendez. Certains des appareils MSP ont des tableaux d'étalonnage DCO programmés dans l'un des secteurs flash à la fabrication, mais ils ne sont utiles que s'ils couvrent la fréquence que vous souhaitez utiliser, et je ne pense pas qu'ils aient des valeurs de compensation de température.

Avez-vous un oscillateur à cristal de référence que vous pourriez utiliser comme source d'étalonnage? Je conçois toujours dans un cristal à 32 kHz et je l'utilise sur l'ACLK. Pour des débits en bauds jusqu'à 9600, cela peut être utilisé directement. Pour des débits plus élevés, vous devrez calibrer le DCO par rapport au signal ACLK. Les pièces les plus récentes ont un FLL matériel qui le fera automatiquement.

uɐɪ
la source
7

Voici donc la réponse:

Le produit a un cristal de 32 kHz, et j'avais codé une routine pour ajuster la fréquence DCO. Le réglage de la fréquence a utilisé deux minuteries, une de DCO et une de ACLK à 32 kHz. Il a été entraîné par une interruption du système de capture / comparaison, de sorte qu'il pouvait se recalibrer périodiquement pendant le fonctionnement.

Malheureusement, j'ai inséré l'étalonnage initial dans la mauvaise partie de mon code de démarrage, où les interruptions ont été désactivées. Par conséquent, l'étalonnage ne s'est pas produit avant la première utilisation du port série, et l'initialisation se bloquait en attendant une réponse sur le port série.

La fréquence DCO commence à la valeur calibrée en usine, c'est pourquoi elle fonctionnait à température ambiante.

Ces intrigues racontent l'histoire:

Tout d'abord, la courbe DCO-température: texte alternatif

Maintenant, la courbe après l'étalonnage fonctionne réellement: texte alternatif

markrages
la source
1
Belle histoire! Cela a-t-il coûté cher à réparer? : D
tyblu
Il est intéressant de noter que la pente passe du premier graphique au deuxième graphique. Des théories? Le réglage de la fréquence du DCO plus bas lui donne-t-il un coefficient de température pire?
W5VO
Notez que l'axe des y change entre les deux graphiques. Et ne les lisez pas trop en général. La pièce a été congelée dans un congélateur domestique et la température a été mesurée pendant le réchauffement à température ambiante avec un thermocouple sur un MAS-345 bon marché ( elexp.com/tst_s345.htm ) qui ne lit que des degrés entiers. Ensuite, j'ai interpolé linéairement entre les changements de degré entier pour créer l'intrigue.
markrages
5

Les basses températures ont fait monter la fréquence DCO suffisamment pour faire monter le débit en bauds UART trop haut? Vous avez mesuré la température et ensuite compensé l'oscillateur dans le logiciel?

W5VO
la source