Comunicazione seriale MSP430 non riuscita con tempo freddo


8

Ho un prodotto che utilizza il microprocessore MSP430, che vende da un paio d'anni. Uno dei lavori di MSP430 è quello di comunicare via seriale asincrona a una radio a basso consumo.

Con l'inizio di questo inverno, si è verificato un tasso di fallimento inaccettabile (diversi percento) a basse temperature. L'indagine ha rilevato che la comunicazione seriale con la radio non riesce. Il generatore di baudrate per la porta seriale è alimentato da SMCLK, che è diviso dall'oscillatore a controllo digitale (DCO) dell'MSP430.

Perché la comunicazione seriale non riesce a basse temperature?

(Nota: ho già risolto il problema e pubblicherò presto la risposta. Suggerimento: era un bug del software.)

Risposte:


8

Quale MSP430 stai usando? Le diverse famiglie hanno strutture e capacità di clock diverse.

Il DCO cambierà frequenza con la temperatura causando il baud rate USART fuori specifica. L'MSP ha un sensore di temperatura (non molto preciso). È possibile modificare i valori nei registri di controllo DCO per riportare la frequenza DCO nell'intervallo, ma ciò richiederebbe tabelle di ricerca calibrate che coprono l'intervallo di temperature che ci si aspetta di vedere. Alcuni dispositivi MSP hanno tabelle di calibrazione DCO programmate in uno dei settori flash durante la produzione, ma sono utili solo se coprono la frequenza che si desidera utilizzare e non credo che abbiano valori di compensazione della temperatura.

Hai un oscillatore a cristallo di riferimento che potresti utilizzare come fonte di calibrazione? Progetterei sempre in un cristallo a 32kHz e lo utilizzerei su ACLK. Per baud rate fino a 9600 questo può essere usato direttamente. Per baud rate più elevati dovrai calibrare il DCO rispetto al segnale ACLK. Le parti più recenti hanno un FLL hardware che lo farà automaticamente.


7

Quindi ecco la risposta:

Il prodotto ha un cristallo a 32 kHz e avevo programmato una routine per regolare la frequenza DCO. La regolazione della frequenza utilizzava due timer, uno dal DCO e uno dall'ACLK a 32 kHz. È stato guidato da un interruzione del sistema di acquisizione / confronto, in modo che potesse periodicamente ricalibrarsi durante il funzionamento.

Sfortunatamente, ho inserito la calibrazione iniziale nella parte sbagliata del mio codice di avvio, dove sono stati disattivati ​​gli interrupt. Pertanto la calibrazione non è avvenuta prima del primo utilizzo della porta seriale e l'inizializzazione si sarebbe bloccata in attesa di una risposta sulla porta seriale.

La frequenza DCO inizia al valore calibrato in fabbrica, motivo per cui funzionava a temperatura ambiente.

Queste trame raccontano la storia:

Innanzitutto, la curva della temperatura DCO: testo alternativo

Ora la curva dopo la calibrazione funziona davvero: testo alternativo


1
Bella storia! È costato molto da riparare? : D
tyblu,

È interessante notare che la pendenza cambia dal primo grafico al secondo grafico. Qualche teoria? L'ottimizzazione del DCO in frequenza più bassa gli dà un coefficiente di temperatura peggiore?
W5VO,

Si noti che l'asse y cambia tra i due grafici. E non leggere troppo in essi in generale. La parte è stata congelata in un congelatore domestico e la temperatura è stata misurata durante il riscaldamento a temperatura ambiente con una termocoppia su un MAS-345 economico ( elexp.com/tst_s345.htm ) che legge solo gradi interi. Quindi ho interpolato linearmente tra i cambiamenti di grado intero per creare la trama.
markrages il

5

Le basse temperature hanno causato un aumento della frequenza DCO abbastanza da causare un aumento eccessivo della velocità di trasmissione UART? Hai misurato la temperatura e quindi compensato l'oscillatore nel software?

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.