Cosa potrebbe causare un ripristino inaspettato di un microcontrollore?

Una varietà particolarmente irritante di bug in un sistema controllato da microprocessore è che il microprocessore si resetta inaspettatamente. Uno strumento importante per il debug di questo tipo di problema è un elenco di possibili cause. Cosa potrebbe causare un ripristino inaspettato di un microcontrollore?

Sui chip PIC e dsPIC, ho osservato le seguenti cause di ripristino imprevisto.

Hardware:

• Ripristina pin guidato basso o mobile. Controlla prima le cose ovvie!
• Accoppiamento ESD nel pin di ripristino. L'ho visto accadere quando le apparecchiature completamente estranee vengono accese sulla stessa scrivania. Assicurati che ci sia abbastanza capacità sul pin di reset, possibilmente fino a 1 uF.
• Accoppiamento ESD ad altri pin del processore. In particolare, le sonde di portata possono fungere da antenne, accoppiare il rumore nel chip e causare strani ripristini. Ho sentito segnalazioni di codici di reset "codice operativo non valido".
• Giunto di saldatura difettoso / ponte intermittente. Potrebbe perdere o cortocircuitare un power rail, sul processore o da qualche altra parte sulla scheda.
• Glitch / rumore della barra di alimentazione. Potrebbe essere causato da un numero qualsiasi di problemi esterni, incluso un regolatore danneggiato o un calo dell'alimentazione a monte. Assicurarsi che le barre di alimentazione che alimentano il processore siano stabili. Potrebbe richiedere più cap da qualche parte, forse disaccoppiando il cap direttamente sul processore.
• Alcuni microcontrollori hanno un pin Vcap, che non deve essere collegato a VDD e deve avere un proprio condensatore comune. La mancata connessione corretta di questo pin può avere risultati imprevedibili.
• Guidare un ingresso analogico negativo oltre un certo limite provoca un reset che riporta in RCON come un brownout. Lo stesso può valere per gli ingressi digitali.
• DV / dt molto elevati in un convertitore di potenza nelle vicinanze possono causare un reset del brownout. (Vedi questa domanda .) L'ho visto in due casi e in uno sono stato in grado di rintracciarlo su accoppiamento capacitivo. Un IGBT stava commutando 100-200 amp, e allo spegnimento alcuni circuiti di feedback stavano vedendo alcuni microsecondi di rumore, passando da 2 V a oltre 8 V su un processore da 3,3 V. Aumentando il tappo del filtro su quel binario di feedback, i ripristini si sono interrotti. Si potrebbe immaginare che l'aggiunta di un filtro dV / dt attraverso il transistor avrebbe potuto avere un effetto simile.

Software:

• Timer di controllo. Assicurati che il timer del watchdog sia cancellato abbastanza spesso, specialmente nei rami del tuo codice che potrebbero richiedere molto tempo per essere eseguiti, come scrive EEPROM. Prova per questo disabilitando il watchdog per vedere se il problema scompare.
• Dividere per zero. Se si sta eseguendo ogni operazione di divisione nel codice, assicurarsi che il divisore non può mai essere uguale a zero. Aggiungi un controllo dei limiti prima della divisione. Non dimenticare che questo vale anche per le operazioni del modulo .
• Stack overflow. Troppe chiamate di funzione nidificate possono causare l'esaurimento della memoria dinamica per lo stack del sistema, che può causare arresti anomali in punti insoliti nell'esecuzione del codice.
• Stack underflow. Se si sta programmando in assembler, è possibile eseguire accidentalmente più RITORNI di quelli eseguiti CHIAMATE.
• Routine di interrupt inesistente. Se un interrupt è abilitato, ma non viene definita alcuna routine di interrupt, il processore potrebbe reimpostarsi.
• Routine di trap inesistente. Simile a una routine di interrupt, ma abbastanza diverso, lo sto elencando separatamente. Ho visto due progetti separati usando dsPIC 30F4013 che si resettavano casualmente e la causa è stata rintracciata in una trappola chiamata ma non definita. Naturalmente, ora hai la domanda sul perché viene chiamata in primo luogo una trappola, che potrebbe essere un numero qualsiasi di cose, incluso l'errore al silicio. Ma definire tutti i gestori di trap dovrebbe probabilmente essere un buon primo passo nella diagnosi di reset inspiegabili.
• Errore del puntatore a funzione. Se un puntatore a funzione non punta a una posizione valida, il dereferenziamento del puntatore e la chiamata alla funzione indicata possono causare un ripristino. Una causa divertente di ciò è stata quando stavo inizializzando una struttura, con valori successivi di NULL (per un puntatore a funzione) e -1 (per un int). La virgola è stata digitata, quindi il puntatore alla funzione è stato inizializzato su NULL-1. Quindi non dare per scontato che solo perché è un CONST deve contenere un valore valido!
• Indice di array non valido / negativo. Assicurarsi di eseguire il controllo dei limiti su tutti gli indici dell'array, sia i limiti superiore che inferiore, se applicabile.
• Creazione di un array di dati nella memoria del programma che è più grande della sezione più grande della memoria del programma. Questo potrebbe anche non generare un errore di compilazione.
• Trasmettere l'indirizzo di una struttura a un puntatore a un altro tipo, dereferenziare quel puntatore e usare il puntatore senza referenza come LVALUE in un'istruzione può causare un arresto anomalo. Vedere questa domanda . Presumibilmente, questo vale anche per altri comportamenti indefiniti.

Su alcuni dsPIC, il registro RCON memorizza i bit che indicano la causa del reset. Questo può essere molto utile durante il debug.

Il pin RESET deve essere correttamente pilotato da un circuito di reset che controlla la sovratensione / sottotensione e crea un segnale di reset sufficientemente lungo. Tenendo presente ciò, le mie esperienze con un reset hardware non controllato provengono quindi da:

• Crosstalk da commutazione di linee nel pin / linea RESET (renderle brevi)
• Spostamenti a terra / loop causati dall'accensione / spegnimento del carico esterno ad alta corrente
• Picco di tensione non filtrato dall'alimentazione e troppo corto per attivare il RESET corretto
• Commutazione di carichi esterni da parte del microcontrollore che causa problemi di cui sopra (principalmente su carichi induttivi come accensione / spegnimento del motore, relè o vecchia lampada (corrente di spunto)
• Il picco di tensione / corrente su uno qualsiasi dei pin del microcontrollore (peggio è l'oscillatore) può causare corrente inversa e può commutare il registro interno (come i picchi di tensione sulla linea di alimentazione). In generale, quando si interfaccia a un tipo di ambiente industriale è necessario prestare attenzione (per ulteriori informazioni, consultare: http://www.ichaus.biz/wp1_mcu_interface ). Devono essere considerati lo spostamento di livello su IO, il filtro di ingresso e le uscite di commutazione soft. Rendere pulite le linee di alimentazione ha la prima priorità dal lato hardware. Quindi RESET e pin dell'oscillatore, quindi linee IO. -mm

Un'ulteriore possibilità che non ho visto in questo elenco è un dispositivo che supporta ICSP. Se vengono utilizzati pull up insufficienti sulle linee che si attivano in modalità di programmazione seriale del circuito, a volte è possibile accedere a tale modalità in modo casuale. Ciò porta a un ripristino dopo un breve intervallo quando non viene inviato alcun aggiornamento del programma alle linee del ricevitore seriale designate. Sospetto che un timer interno del watchdog imponga il ripristino se l'ICSP viene avviato e non vengono inviati dati di programmazione. Questo è un errore che ho fatto e che ho trascorso molto tempo a trovare con un 16F876.

Assicurati di utilizzare chip logici CMOS o TTL nel tuo circuito in modo che dispongano di adeguati condensatori di disaccoppiamento tra Vdd e massa (di solito 0,1 uF). Stavo usando un CD4021 in un progetto e quando era in uso, apparentemente stava causando un picco che stava causando il riavvio del microprocessore. Quindi il ciclo si ripeterebbe. Questo è anche il motivo per cui è una buona idea mettere una sequenza di test ovvia (come accendere e spegnere un LED alcune volte) all'inizio del codice in modo da sapere che il microprocessore funziona ed esegue il codice.

Questa è una di quelle cose rare che potrebbero apparire:

Avevo un progetto che prevedeva un microcontrollore e si ripristinava sporadicamente. Per farla breve, risulta che alcune opzioni devono essere abilitate o disabilitate, altrimenti potrebbero verificarsi dei ripristini. L'ho scoperto solo leggendo l'errata dopo aver rinunciato a tutto il resto.

Ora ho l'abitudine di leggere gli errata prima ancora di decidere di usare un chip per sapere in cosa mi sto cacciando e se è qualcosa che riesco a gestire. Sfortunatamente, dopo la laurea, non avevo davvero nessuno che mi educasse sulle pratiche comuni, quindi gran parte del mio apprendimento nel mondo reale è stato attraverso il fallimento e la frustrazione.