Usiamo i microcontrollori ATmega48 / 88/168/328 con successo da molti anni in molti dei nostri prodotti. Abbiamo ora considerato di passare dalle varianti A e PA alla nuova variante PB (perché avremo bisogno di pin, timer e UART extra nei nuovi prodotti, perché è diventato più economico e perché sembra che le vecchie varianti saranno interrotte), quindi abbiamo sostituito un ATmega328A con un ATmega328PB. Sembra andare in tilt molto spesso dopo interruzioni di corrente . Tali problemi non si sono mai verificati con le vecchie varianti.

Interruzioni di corrente regolari sono normali per il caso d'uso dei nostri prodotti. Usiamo un alimentatore switching (come questo ) impostato su 5V e abbiamo condensatori nella gamma 220µF sul VCC dell'ATmega, per mantenere in vita la SRAM per interruzioni di corrente nella gamma di diversi minuti, per memorizzare stati interni che non sono mission critico ma aumenta significativamente l'esperienza utente essendo immediatamente disponibile al riavvio (questi stati cambiano abbastanza spesso da rendere EEPROM inadatta). Questo ha sempre funzionato.

Tuttavia, con il nuovo ATmega328PB, dopo un'interruzione di corrente, il chip si reimposta senza che sia stata trovata una condizione di ripristino in MCUSR e l'orologio sembra andare in tilt.

• il rilevatore brown-out è impostato per fusibile. Abbiamo provato tutti i livelli disponibili, il bug si verifica su tutti.
• utilizziamo 20 MHz esterni, anch'essi impostati correttamente per fusibile.
• abbiamo provato 3 chip diversi, quindi non è stata una singola saldatura o altri guasti hardware.

Dopo che si è verificato il bug, l'orologio spesso imposta una velocità più lenta di 2,5 volte, indicando che l'oscillatore interno a 8 MHz sta controllando il mcu. Tuttavia, a volte il rallentamento è di circa 6 volte. Ciò significa che non può essere un bug del software che modifica il divisore di clock, poiché non riesco a impostare i fusibili dal software e il divisore di clock non può dividere l'orologio per 2,5 o 6.

Quindi, il mio primo sospettato è stato il nuovo fusibile di rilevamento guasti dell'orologio. Tuttavia, indipendentemente dal fatto che sia attivato o disattivato, il comportamento rimane lo stesso.

Per escludere le peculiarità del software, ho scritto da zero un semplice programma di test, che non fa altro che commutare un'uscita a 100 Hz dall'interruzione del timer e indica con LED dopo ogni riavvio quali condizioni di ripristino sono state attivate (come letto da MCUSR). Anche il resto dell'hardware è stato rimosso, ci sono solo la mcu e il regolatore (e l'indicatore si illumina con resistori in serie).

I risultati

Circa i 2/3 del tempo, non succede nulla di interessante. Dopo l'interruzione dell'alimentazione, la mcu riprende il suo lavoro, si accendono sia gli indicatori di reset brown-sia il reset di accensione.

(sull'immagine, il rosso è il perno attivato / disattivato e il blu è VCC. Su questa immagine, il mascheramento da 2,7 V è chiaramente visibile. Ho fatto gli stessi test con le altre impostazioni di brown-out, i risultati sono esattamente gli stessi, quindi ometterò quelle foto)

Circa 1/3 del tempo, si verifica il suddetto errore e quando viene ripristinata l'alimentazione, nessuno degli indicatori di reset brown-out e power-on si accende! L'output è diverso, come se il mcu stesse ticchettando con uno strano orologio. Non è caotico, tuttavia, continua a ticchettare con la stessa frequenza.

È interessante notare che, in questa situazione, il rivelatore brown-out sembra essere completamente inattivo, perché dopo la successiva interruzione dell'alimentazione (dove a volte viene ripristinato l'orologio corretto, a volte no), è chiaramente visibile che l'uscita continua a commutare bene dopo il brown- fuori livello è stato superato. In tali situazioni, l'orologio a volte diventa più veloce, altre volte diventa più lento:

Durante questi test ho usato 16K CK / 14CK + 4,1 ms per il ritardo di avvio (ma il ritardo di 65 ms non evita i problemi).

Ecco un'immagine ingrandita, in cui puoi vedere chiaramente che il VCC raggiunge uno stato stabile a 5 V in meno di 2 ms:

Nell'immagine sopra, l'MCU è stato avviato correttamente.

È interessante notare che, in caso contrario, la tensione di alimentazione arriva fino a 5 V stabile anche prima (sembra che molte parti del mcu non si accendano, quindi assorbe meno corrente durante l'avvio)

Di seguito è un'immagine da un inizio non riuscito:

Si noti che il software inizia a funzionare dopo più di 85 ms dopo che la tensione di alimentazione è stata stabilizzata, anziché i 10,5 ms richiesti diversamente. I fusibili per il ritardo all'avvio sono sempre gli stessi, 16K CK / 14CK + 4,1 ms.

La cosa interessante da notare è che dopo che l'alimentazione è stata interrotta, il VCC si stabilizza da circa 1,1 a 1,2 Volt (la vecchia variante ATmega328A è scesa a circa 0,6 - 0,7 V). Lo mantiene per diversi minuti. Se aspetto abbastanza (nell'ordine di mezz'ora o più), l'MCU si avvia sempre correttamente! Quindi sembra che il problema sia che ci sono 1,1 Volt in giro, che, secondo il foglio dati, non è garantito per essere sufficiente per un reset all'accensione. Ma dovrebbe essere sufficiente per un reset brown-out!

Ad eccezione di queste situazioni, il rilevatore brown-out funziona bene. È visibile sulla prima immagine (il segnale di uscita si interrompe quando viene raggiunto il livello del corpo e la caduta di tensione rallenta quando vengono chiuse parti dell'MCU). Ho fatto dei test quando ho ridotto il VCC leggermente al di sotto del livello del corpo e lasciato che risalisse di nuovo, l'MCU si riavviava sempre correttamente in tali condizioni, con solo l'indicatore di reset brown-out acceso.

Mi sono perso qualcosa di ovvio o l'ATmega328PB ha un grave bug nel suo rilevatore brown-out?

MODIFICARE:

È interessante notare che i problemi di cui sopra sorgono solo quando interrompo l'alimentazione prima del regolatore. Se lo interrompo dopo il regolatore (o utilizzo un alimentatore da laboratorio), i problemi non si verificano mai. Come se la forma della tensione in aumento causasse i problemi. Tuttavia, come puoi vedere dall'ultima immagine, l'aumento di tensione è abbastanza bello e si stabilizza rapidamente.

MODIFICA 2

L'ho provato con 16 MHz anziché 20 MHz, ma si verificano esattamente gli stessi problemi.

Non penso che sia un bug con il rilevatore brown-out, ma come usi il chip.

Come hai detto tu stesso, la soglia di ripristino all'accensione 1,1 V non viene raggiunta se l'alimentazione viene rimossa e collegata brevemente, quindi non ci sarà POR.

Anche il rilevatore brown-out non può aiutare molto qui. Stai utilizzando l'AVR a 20 MHz e ciò richiede che la tensione di alimentazione sia di 4,5 V o superiore, oppure stai violando le specifiche. E BOD non garantisce che inciamperà a 4,5 V, in genere è inferiore a quello, diciamo 4,3 V. Quindi, anche prima che BOD si inneschi, non esiste alcuna garanzia in quale stato finisce l'AVR ma il BOD dovrebbe attivarsi, tranne che potrebbe non funziona a causa del tuo clock a 20 MHz. Quando la tensione ricomincia a salire, il BOD si disattiva prima che la tensione di alimentazione sia di nuovo a un livello sicuro di 4,5 V. Se è stato attivato correttamente. Il tempo di ritardo all'avvio dovrebbe quindi essere impostato su un valore sufficientemente alto da consentire alla tensione di passare da un livello di disattivazione BOD a 4,5 V prima che venga rilasciato il ripristino interno.

Ma potrebbe non funzionare perché ha bisogno di almeno 4,5 V per funzionare a 20 MHz. La scheda tecnica AVR menziona che se il sistema di ripristino interno non è adatto, utilizzare un chip di ripristino esterno e in questo caso sembra che risolverebbe i problemi per ripristinare l'AVR prima che la tensione scenda a 4,5 V.