Ich habe mich noch nie mit defekten Teilen von digikey beschäftigt, aber 3 neue Atmel ATmega164A, die ich erhalten habe, haben ein extrem seltsames Verhalten gezeigt.
Ich habe es auf etwas eingegrenzt, das mit dem Takt zu tun hat, und es stellte sich heraus, dass das resultierende Taktsignal des angeblich "werkseitig kalibrierten" internen Oszillators zwischen 650 und 700 kHz zitterte, anstatt der soliden 1 MHz, die es sein sollte. Ich konnte in das Kalibrierungsbyte schreiben, um dies sehr nahe an 1 MHz zu bringen (immer noch mit etwas Jitter), und die meisten Dinge funktionieren, aber die UARTs verhalten sich einfach nicht richtig, sie scheinen einen kontinuierlichen Strom kurzer Impulse auszugeben, egal worum du sie bittest.
Ich habe mich zuvor mit der Low-Power-Version dieses Mikrocontrollers (164P) ohne Probleme befasst und beschlossen, ihn an Ort und Stelle fallen zu lassen und den Taktausgang darauf zu überprüfen, und es sind solide 1 MHz ohne Jitter. Ich neige zu dem Schluss, dass diese 164A-Chips defekt sind, aber gäbe es andere Tests, mit denen ich versuchen könnte, dies zu bestätigen?
Bearbeiten: Ich dachte nur, ich würde den Prozess beschreiben, mit dem ich die Uhr messe. Ich habe das Sicherungsbit des Taktausgangs aktiviert und den entsprechenden Pin mit einem Logikanalysator gemessen, der mit einer sehr hohen Rate abtastet. Ich habe ein Programm, das in das Kalibrierungsregister schreibt, OSCCALund ich konnte mich durch Versuch und Irrtum auf 1 MHz begeben.
Bearbeiten Nr. 2: Nach weiteren Untersuchungen scheint der Mikrocontroller nach einer bestimmten Programmgröße zu reagierenSchwelle. Ein Bare-Bones-Projekt mit einer einzigen Quelldatei, die eine LED blinkt, scheint in Ordnung zu sein, aber das Kompilieren und Verknüpfen einer meiner anderen Dateien (z das oben beschriebene Verhalten. Die Stromanschlüsse sind in Ordnung und es wurde eine ordnungsgemäße Entkopplung durchgeführt. Ich habe im Moment keine Zeit, dies weiter zu debuggen, also haben wir stattdessen mit der Low-Power-Version weitergemacht. Ich bin mir nicht sicher, wo genau das Problem liegen könnte, entweder 1) 164A und 164P sind nicht codekompatibel 2) Programmierverfahren ist für diese beiden uCs unterschiedlich 3) Einheiten sind defekt. Ich bin von unserem Board-Design überzeugt und würde Stromversorgungsprobleme ausschließen. Leider kann ich nicht wirklich eine richtige Antwort auswählen, also lasse ich diese Frage so wie sie ist - vielleicht habe ich' Werde in Zukunft noch einmal auf das Problem zurückkommen. Vielen Dank an alle, die aufschlussreiche Kommentare oder Antworten gegeben haben, sie könnten jemand anderem mit uC-Problemen sofort nützlich sein.
So einen Ausfall hat man selten. Sie könnten erwarten, dass ein Stift etwas mehr Rauschen sieht oder dass dieser Stift vollständig funktionsunfähig ist. Aber dass es "etwas funktioniert, aber nicht auf sinnvolle Weise" ist, ist selten. Ich würde vermuten, dass es Designprobleme gibt, die die Probleme verursachen und etwas mit einem Unterschied zwischen dem 164A und dem 164P zu tun haben. Da der Jitter hoch ist, würde ich mir die leistungsbezogenen Dinge ansehen. Sind alle Power/Gnd-Pins verbunden? Werden die I/O-Pins entweder angesteuert oder auf High oder Low gezogen? Usw.
Aber es bleibt immer noch die Möglichkeit, dass die Teile schlecht sind. Es ist selten, aber nicht unerhört. Die einzige wirkliche Möglichkeit, dies festzustellen, besteht darin, weitere Teile von einem anderen Lieferanten zu besorgen und sie auszuprobieren. Wenn sie funktionieren, müssen Sie weiter nachforschen und sehen, ob Sie sie beim Handhaben/Löten getötet haben oder ob sie wirklich schlecht von Digikey stammen.
Ich hatte einmal ein sehr ähnliches Problem mit Basisteilen von Microchip. Wir haben die ICSP-Programmierung durcheinander gebracht und einen Weg gefunden, die Oszillatortrimmung zu löschen, was zu groben Fehlern in der Genauigkeit der internen Uhr führte. Stellen Sie sicher, dass Ihre Programmiervorrichtung und/oder Programmierwerkzeuge richtig angeschlossen sind und richtig verwendet werden.
Es gibt keine einfache Möglichkeit, die Genauigkeit des Oszillators zu überprüfen, ohne die Teile zu programmieren, also würde ich einfach ein triviales Port-Toggle-Programm schreiben (eines, das nichts anderes tut, als an einer E / A-Leitung wackeln) und jemand anderen programmieren lassen Teilen, vorzugsweise mit unterschiedlicher Programmierhardware. Sobald Sie das Wackeln überprüft haben, können Sie mit Ihrem eigenen Code neu flashen und sehen, ob das Problem weiterhin besteht.
Kellenjb
Kortuk
Jon L
Kellenjb
Jon L
Olin Lathrop
Garret Fogerlie
Jon L