Non ho mai avuto a che fare con parti difettose dello stretto di digikey, ma 3 nuovi Atmel ATmega164A che ho ricevuto hanno mostrato un comportamento estremamente strano.
L'ho limitato a qualcosa a che fare con l'orologio e ho scoperto che il segnale di clock risultante dall'oscillatore interno presumibilmente "calibrato in fabbrica" stava oscillando tra 650-700 kHz invece del solido 1 MHz che dovrebbe essere. Sono stato in grado di scrivere nel byte di calibrazione per avvicinarmi molto a 1 MHz (sempre con un po 'di jitter) e la maggior parte delle cose funziona ma gli UART non si comportano correttamente, sembrano emettere un flusso continuo di impulsi brevi, non importa cosa chiedi loro di fare.
In precedenza ho affrontato la versione a bassa potenza di questo microcontrollore (164P) con zero problemi e ho deciso di rilasciarlo in posizione e controllare l'uscita del clock su quello, ed è un solido 1 MHz senza jitter. Sono propenso alla conclusione che questi chip 164A sono difettosi, ma ci sarebbero altri test che potrei provare a confermare?
Modifica: ho pensato di descrivere il processo attraverso il quale sto misurando l'orologio. Ho abilitato il bit del fusibile di uscita del clock e ho misurato il pin appropriato con un analizzatore di logica che campionava a una velocità molto elevata. Ho un programma che scrive nel registro di calibrazione OSCCALe sono stato in grado di provare ed errori a 1 MHz.
Modifica n. 2: dopo ulteriori accertamenti, sembra che il microcontrollore inizi a funzionare dopo una determinata dimensione del programmasoglia. Un progetto bare-bones con un singolo file sorgente che lampeggia un LED sembra essere OK, ma la compilazione e il collegamento in uno qualsiasi dei miei altri file (diciamo la libreria UART o altro) senza nemmeno effettuare una chiamata di funzione a quei metodi fa sì che il microcontrollore si comporti in il comportamento descritto sopra. Le connessioni di alimentazione vanno bene ed è stato esercitato il corretto disaccoppiamento. Al momento non ho tempo per eseguire il debug di questo, quindi siamo andati avanti con la versione a basso consumo. Non sono sicuro di dove possa essere esattamente il problema 1) 164A e 164P non sono compatibili con il codice 2) La procedura di programmazione è diversa per questi due UC 3) Le unità sono difettose. Sono fiducioso nel design della nostra scheda e escluderei problemi di potenza. Sfortunatamente, non riesco davvero a scegliere una risposta corretta, quindi lascio questa domanda così com'è - forse io ' Tornerò di nuovo al problema in futuro. Grazie a tutti coloro che hanno fornito commenti o risposte perspicaci, potrebbero essere utili a qualcun altro con problemi di controllo immediato.