Ich habe eine falsch signierte ATmega328-PU. Wie kann ich das beheben?

12

Irgendwann in der Vergangenheit habe ich mit der Arduino IDE Bootloader auf eine neue Charge von vier ATmega328-PU gebrannt (beachten Sie, dass es nach 328 kein P gibt - es ist die etwas billigere Nicht-Picopower-Version der MCU, nicht zu verwechseln mit der ATmega328P- PU mit einem P ) und war überrascht mit der folgenden Nachricht von avrdude:

avrdude: Device signature = 0x1e950F 
avrdude: Expected signature for ATMEGA328 is 1E 95 14 
Double check chip, or use -F to override this check. 

Das bedeutet, dass avrdude dachte, der Chip sei nicht das, was sein Label sagte. Dann habe ich den Chiptyp auf meiner Arduino IDE auf ATmega328P-PU geändert und avrdude hat den Bootloader ohne Beschwerden gebrannt. Dies bedeutet, dass der Chip als eine MCU bezeichnet wurde und intern als eine andere, geringfügig andere, antwortete.

Was ich gerne wissen würde ist:

  • Wie selten ist dieses Ereignis? Hat jemand eine ähnliche Erfahrung gemacht? ( Ursprüngliche Frage, Off-Topic )

  • Ist es möglich, dies zu beheben? Wie kann ich die Signatur korrigieren, damit avrdude den Chip richtig erkennt?

Dies ist eine Quer Post von EE.SE . Ich habe diese Frage dort gepostet, aber nicht viel Aufmerksamkeit erregt. Deshalb wollte ich sehen, ob jemand aus unserer Community eine ähnliche Erfahrung gemacht hat.

Ricardo
quelle
1
Es scheint, dass Ihr Anbieter einige 328Ps (für die diese Signatur steht) einfach als 328s falsch etikettiert hat.
microtherion

Antworten:

4

Beim Durchstöbern von sparkfun habe ich mehrere News-Posts gefunden, die ihren Kampf mit falsch beschrifteten Chips zeigen. Hier sind ein paar:

Sparkfun hatte von einem neuen Verkäufer in China eine fragwürdige Lieferung erhalten. Sie beschlossen, sie zu testen, bevor sie in Produktion gingen, und keines ihrer Testboards funktionierte. Mit Salpetersäure konnten sie das Gehäuse der ICs entfernen und ein Stück Metall herstellen, das aussah wie Kupfer.

In einem anderen Artikel sezierten sie einige verdächtige ICs von Atmel und fanden darin einen ON-Halbleiter-Siliziumwafer. Die Chips waren keine funktionellen ATmegas, aber sie hatten im Gegensatz zu den anderen Silizium.

Der Doktor
quelle
3
Können Sie diese Antwort ein wenig ausarbeiten? Das Zusammenfassen der Artikel, mit denen Sie verlinkt sind, ist ein guter Anfang. Wenn der Funfun aus irgendeinem Grund ausfällt, ist Ihre Antwort wertlos.
Shog9
@ Shog9 Warum? Die Frage ist weit weg von der Basis. Diese Antwort ist eine Zusammenfassung von Fällen, in denen Personen falsch etikettierte Chips erhalten (im Wesentlichen Personen, die Erfahrungen austauschen ). Wem wird das helfen?
Asheeshr
Ich könnte Sie das gleiche fragen, @AsheeshR - warum sich um eine Antwort sorgen, wenn die Frage das Problem ist? Wie auch immer, danke für das Hinzufügen des Details, TheDoctor.
Shog9
3

Dies ist nicht die bevorzugte Methode, um Probleme zu beheben, und sicherlich nicht die erste Lösung, die in Betracht gezogen werden muss. Sie können jedoch auch die Signaturbytes programmieren. Bevor Sie dies versuchen, stellen Sie unbedingt sicher, dass Sie dies wirklich tun möchten, und Sie haben untersucht, was erforderlich ist, um dies rückgängig zu machen. Dies kann dazu führen, dass Konfigurationsdateien auf Ihrem Computer geändert werden ...

Wie auch immer, die Art und Weise, wie die Signaturbytes des Controllers gesetzt werden, ist wie folgt (ungetestet, ich habe keinen freien AVR herumliegen):

avrdude -p atmega328 -c arduino -P /dev/ttyUSB003 -b 19200 -v -U signature:w:0x1E,0x95,0x14:m
jippie
quelle
2
Ich weiß, dass dies sehr spät ist, aber ich halte es nicht für eine gute Idee, dies als die akzeptierte Antwort unangefochten stehen zu lassen: Die Signatur auf einem atmega328 ist nicht beschreibbar, und meines Wissens ist die Signatur auf JEDEM atmega oder nicht beschreibbar attiny.
microtherion
2
Aus Interesse habe ich den obigen Ansatz ausprobiert, der in gewissem Sinne akzeptiert wurde: avrdude: writing signature (3 bytes)- aber es ist ihm nicht gelungen:avrdude: verification error, first mismatch at byte 0x0002: 0x14 != 0x0f
Nick Gammon