Schadensrate bei neuen Atmegas

Hallo zusammen,

ich wollte ja gerade mal ausprobieren, ob von dem einem IC der EEPROM kaputt ist.. also einen anderen genommen.. lässt sich der Bootloader nicht installieren.. nächster Atmega328 P-PU.. selbes Lied.. nächster.. wieder das selbe..

Am Ende hatte ich jetzt 11 Atmega 328 P-PU durch und das Ergebnis find ich ein wenig schockierend:

6 haben sich bespielen lassen, 5 haben gestreikt. Ist das normal??
Woran liegt das?
Wenn ich den Bootloader aufspielen will, bekomm ich die Meldung:

avrdude: Device signature = 0xffff02
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
Duble check chip, ur use -F to overide this check

Und in der orangen Zeile steht:

Fehler beim Installieren des Bootloaders.

Ich benutz einen DIAMEXAVR-ISP.

Bin ich der einzige, dem's so geht oder gibt's da mehrere?

LG

Fipsi

Die Frage ist, ob es denn auch orginale Atmel Chips sind. Wer weiß was die Chinesen alles kopieren :smiley:
Die meisten MCUs besorg ich mir direkt bei Mouser, wenn ich entsprechende Mengen benötige, ansonsten macht es keinen Sinn.

Du glaubst, dass der Eeprom kaputt ist? Das kann immer mal passieren, aber biste nicht sicher, dass es einfach nur an deinem Sketch liegt. Handelt es sich bei allen Atmega328* um die P Variante?

Warum brauchst du überhaupt den Bootloader?

Ich hab die IC's alle bei reichelt für 1,60 € das Stück gekauft.. da kann man wohl erwarten, dass das kein China-Schrott ist.

Nein.. dass der nicht kaputt ist, haben wir ja mit nem Testsketch widerlegt.. ich dachte aber, dass es in anderer Form am IC liegen kann, sozusagen "überbleibsel von früheren Sketchen".
Ja, es sind alles P-PU's. Der hier.

Den Bootloader installier ich nur, damit die Fuses gesetzt werden.. danach fliegt er ja wieder runter, wenn ich mit dem ISP drüber programmier.
Und auch wenn ich einen Sketch hochladen will, ohne dass ein Bootloader drauf ist/war, bricht mehr der ab und sagt, dass der Atmega nicht antwortet.

LG

Fipsi

Zuerst mal eine gute Nachricht: das EEPROM ist sicher nicht kaputt da der Sketch / Bootloader ins Flash geladen wird.

Ok, Du hast einen DIAMEXAVR-ISP, Wie verbindest Du den ATmega mit dem Programmierer?

Grüße Uwe

hi,

versuch', die chips nicht an den pins zu berühren. gilt für alle ICs, besonders empfindlich ist meiner meinung nach ein FTDI.

wenn Du die mindestbeschaltung für einen atmega auf einem breadboard hast, funkt das nicht immer. nimm mal einen UNO und tausch den 328er dort gegen einen Deiner kaputten aus, und spiel den bootloader über die SPI-pins drauf. die schaltung auf dem UNO ist optimiert. vielleicht geht's ja so...

gruß stefan

Das Schaltbild dazu hab ich im Anhang. Auf der Platine ist das ein Wannenstecker, in den ich über ein Kabel den ISP einsteck.

Nicht an den Pins zu berühren geht ein bisschen schlecht, wenn ich die Pins zusammen biegen muss, damit der IC in den Sockel passt^^. Ich muss jetzt aber auch ehrlich sagen, dass ich darauf noch nie wirklich geachtet hab. Aber auch IC's, die ich schon (übertrieben) 10.000 mal in der Hand hatte, haben noch einwandfrei funktioniert. Die, die meiner Meinung nach beschädigt sind, hab ich frisch aus dem Plastikmagazin.
Mein FTDI ist übrigens in einem durchsichtigen Strumpfschlauch, sodass ich gar keine Pins berühren kann (außer die Stiftleiste und den USB-Stecker).

Ich hab den Atmega auf der Platine, wie sie auch im anhängendem Schaltplan ist.
Ob's auf dem UNO funktioniert kann ich probieren. Aber ich kann da nicht meine IC's einsetzen, weil das ein SMD-Uno ist.

LG

Fipsi

P.S.: Ich hab dann noch mal versucht, auf die 5 vermeindlich defekten den Bootloader zu installieren, bei einem hats dann doch noch geklappt.

Fipsi:
P.S.: Ich hab dann noch mal versucht, auf die 5 vermeindlich defekten den Bootloader zu installieren, bei einem hats dann doch noch geklappt.

Dann sind sie also nicht defekt sondern das Problem liegt anderswo.
Grüße Uwe

Ich weiß nicht ob meine Lösung für andere interessant ist, aber ich erzähle einfach mal.

Ich habe auf einer Streifenraster-Platine einen 28poligen Textool-Sockel mit der Grundbeschaltung eines Atmega 328 P-PU untergebracht.

Bauteile:
2x 100nF Kerko an den Versorgungspins 7+8 und 20+22
2x 22pF Kerko + 16MHz Quarz für den Takt
1x 10poliger Wannenstecker (6polig geht auch, konnte ich aber gerade nicht besorgen)

Der Wannenstecker wird über ein kurzes Flachbandkabel mit einem DIAMEX ALL-AVR Programmer verbunden.
Die Stromversorgung kommt über das Flachbandkabel vom Programmer.

Neue, jungfräuliche Atmega 328 P-PU werden in den Textool-Sockel gesteckt und dann mit der Arduino IDE über -->Tools -->Bootloader installieren, der Bootloader für den UNO draufgepackt.
Das mache ich auch nur um die Fuses richtig zu setzen.

Im nächsten Schritt wird dann der Sketch mit der Arduino IDE über -->Datei -->Upload mit Programmer auf den Controller gebrannt.

Ich habe bisher erst 6 nagelneue 328 P so behandelt.
Viele davon haben inzwischen auch schon die x-te Sketchversion erhalten und es funktionieren immer noch alle.

Bevor man den Controller in den Textool-Sockel steckt sollte man natürlich alle beteiligten Komponenten auf gleiches Potential bringen.
Ich lege den MC auch nur in den Sockel ein oder entnehme ihn dort wenn das USB-Kabel vom Programmer abgezogen ist.

Gruß
Peter

Mich plagten ähnliche Probleme mit frischen Atmegas auf dem Uno Board.

Bei schon gelaufenden, konnte man den Bootloader problemlos austauschen.
Bei nackten sehr unzuverässig.

Geholfen hat das runter setzen der SPI-Taktfrequenz meines USBasp Adapters.
Nackte laufen mit 1MHz.
Unos mit 16MHz

hi,

Mein FTDI ist übrigens in einem durchsichtigen Strumpfschlauch, sodass ich gar keine Pins berühren kann (außer die Stiftleiste und den USB-Stecker).

ich kann's ja nur aus eigener erfahrung berichten:

3 adapter gekauft, bei denen der chip im USB-stecker verbaut ist. 1 gleich nicht erkannt, ok, und nach einer stunde testen ein 2ter kaputt.

3 adapter gekauft, bei denen die chips auf einer platine mit mini-USB verbaut sind. darauf geachtet, daß es zumindest nach beschreibung originale FTDIs sind. alle ok, plötzlich nach einer stunde bauen sind 2 davon kaputt.

ich meine ja nur: vorsichtig sein, auch die steckleiste nicht anfassen.

übrigens: ich bau ja grade platinen für ein ambilight, da brauch ich FTDIs, jetzt sind eben solche platinen zum aufstecken verplant. gibt es auch FTDI-chips im DIP-format? wäre schöner, die direkt auf meine platine zu bringen...

gruß stefan

Wenn alles verloren scheint, einfach mal den Skorpi fragen :wink:

uwefed:
Dann sind sie also nicht defekt sondern das Problem liegt anderswo.
Grüße Uwe

Ich hoff es mal.. wäre mir da aber ehrlich gesagt nicht so sicher.
Was ich halt ein bisschen komisch fand: die defekten IC's hatte ich vorher noch nicht in der Hand und waren in einem Magazin alle hinterinander. Und das sind auch die ersten, die nicht funktionieren - ausgenommen die, von denen ich weiß, das ich sie sicher auf dem gewissen hab.

peter_de:
Ich weiß nicht ob meine Lösung für andere interessant ist, aber ich erzähle einfach mal.

Ich habe auf einer Streifenraster-Platine einen 28poligen Textool-Sockel mit der Grundbeschaltung eines Atmega 328 P-PU untergebracht.

Bauteile:
2x 100nF Kerko an den Versorgungspins 7+8 und 20+22
2x 22pF Kerko + 16MHz Quarz für den Takt
1x 10poliger Wannenstecker (6polig geht auch, konnte ich aber gerade nicht besorgen)

Der Wannenstecker wird über ein kurzes Flachbandkabel mit einem DIAMEX ALL-AVR Programmer verbunden.
Die Stromversorgung kommt über das Flachbandkabel vom Programmer.

Neue, jungfräuliche Atmega 328 P-PU werden in den Textool-Sockel gesteckt und dann mit der Arduino IDE über -->Tools -->Bootloader installieren, der Bootloader für den UNO draufgepackt.
Das mache ich auch nur um die Fuses richtig zu setzen.

Im nächsten Schritt wird dann der Sketch mit der Arduino IDE über -->Datei -->Upload mit Programmer auf den Controller gebrannt.

Ich habe bisher erst 6 nagelneue 328 P so behandelt.
Viele davon haben inzwischen auch schon die x-te Sketchversion erhalten und es funktionieren immer noch alle.

Bevor man den Controller in den Textool-Sockel steckt sollte man natürlich alle beteiligten Komponenten auf gleiches Potential bringen.
Ich lege den MC auch nur in den Sockel ein oder entnehme ihn dort wenn das USB-Kabel vom Programmer abgezogen ist.

So mach's ich ja auch. Abgesehen davon, dass noch ein paar Bauteile mehr an der Platine sind: Quarz, 2x 22 pF, 7x 100 nF, 4x Widerstand, ansonsten nur Buchsen-/Stiftleisten.

combie:
Mich plagten ähnliche Probleme mit frischen Atmegas auf dem Uno Board.

Bei schon gelaufenden, konnte man den Bootloader problemlos austauschen.
Bei nackten sehr unzuverässig.

Geholfen hat das runter setzen der SPI-Taktfrequenz meines USBasp Adapters.
Nackte laufen mit 1MHz.
Unos mit 16MHz

Die Frquenz lässt sich aber nur im Atmel Studio runter setzen, oder? Ich benutzt ja nur den IDE (würde ich auch lieber so lassen, was ich so gehört hab, kann man im Studio jede Menge kaputt machen.. und dafür hab ich ein Händchen unschuldig pfeif.

Eisebaer:
hi,

ich kann's ja nur aus eigener erfahrung berichten:

3 adapter gekauft, bei denen der chip im USB-stecker verbaut ist. 1 gleich nicht erkannt, ok, und nach einer stunde testen ein 2ter kaputt.

3 adapter gekauft, bei denen die chips auf einer platine mit mini-USB verbaut sind. darauf geachtet, daß es zumindest nach beschreibung originale FTDIs sind. alle ok, plötzlich nach einer stunde bauen sind 2 davon kaputt.

ich meine ja nur: vorsichtig sein, auch die steckleiste nicht anfassen.

übrigens: ich bau ja grade platinen für ein ambilight, da brauch ich FTDIs, jetzt sind eben solche platinen zum aufstecken verplant. gibt es auch FTDI-chips im DIP-format? wäre schöner, die direkt auf meine platine zu bringen...

gruß stefan

Ich hab so einen hier, hatte bisher eigentlich noch keine Probleme und der lebt imerhin schon seit Ende Februar bei mir^^.

skorpi08:
Wenn alles verloren scheint, einfach mal den Skorpi fragen :wink:

Du weißt also, woran's liegt? Raus damit! :stuck_out_tongue: ^^

LG

Fipsi

Keine Ahnung ob es von Bedeutung ist:

Du hast am Reset Pin noch einen Kondensator und einen Widerstand.
Ich weiß, das ist beim original UNO genau so.
Aber beim original UNO ist auch noch eine Diode parallel zum Widerstand und die hast du nicht drin!

Wie ist es mit dem MAX487? Ist der beim flashen in der Schaltung?
Dann gibt es auch bei dir noch den Elko C9 mit 10µF der an der Versorgungsspannung hängt.

Vielleicht liefert dein Brenner nicht genügend Strom auf der 5V Leitung und die Spannung bricht beim flashen ein weil noch zusätzliche Bauteile versorgt werden. Das könnte erklären dass es manchmal geht.

Ich kann mir nicht wirklich vorstellen dass die Bauteile die du zusätzlich verschaltet hast oder die nicht vorhandene Diode ein Problem sind. Aber der Teufel ist ein Eichhörnchen.

Ich habe mir die beschriebene Platine nur zum flashen gebaut. Auf den Platinen auf denen meine Controller später laufen habe ich keine ISP Stecker vorgesehen.
Bei Änderungen muss ich also den Controller aus der Anwendungsplatine ziehen und auf der Flashplatine stecken. Das ist nicht wirklich mehr Aufwand. Bevor ich den Laptop in den Garten schleppe um dort ein Programm zu ändern, mach ich mir lieber einen neuen Controller fertig und tausche den im Garten gegen den dort vorhanden.

Und bei Transport, Lagerung und Handling stecken meine Controller immer in Leitschaumstoff.

Gruß
Peter

Fipsi:
...
So mach's ich ja auch. Abgesehen davon, dass noch ein paar Bauteile mehr an der Platine sind: Quarz, 2x 22 pF, 7x 100 nF, 4x Widerstand, ansonsten nur Buchsen-/Stiftleisten.
...

Habe gerade gesehen dass es beim original UNO doch keinen Kondensator vom Resetpin nach GND gibt.
Der Kondensator dort hängt in Reihe mit einem 1k Widerstand an GND.

Das lässt die Sache schon ganz anders aussehen.
Wenn von deinem Brenner beim flashen ein Impuls an den Reset des Controllers geschickt wird kommt der dort nur verwaschen an !!!!!!!!!

Nein, es sind nur die Bauteile vorhanden, die ich vorhin gesagt hab. Also auch kein MAX und die Elko's ebenfalls nicht.

Ich hab den ISp-Stecker absichtlich auf der Anwendungsplatine, weil ich das Teil ja später im Turnierbetrieb ja auch verwende. Zumindest für die Prototypen hab ich die und die serielle Schnittstelle mit auf dem Board, damit ich nicht immer erst ewig umstecken muss.
Wenn später das ganze stabil läuft, kann ich das ja von den Platinen entfernen und - so wie du's auch hast - eine extrige Platine dafür anfertigen. Aber momentan ist mir das lieber.

Und es ist ja nicht so, dass es mal hier, mal da geht/nicht geht. Sondern es sind die 4 gleichen IC's, die nicht wollen. Bei den anderen bisher getesteten (7 Stk.) traten bisher keine Probleme auf.

Der Reset-impuls kommt doch erst am Ende vom flashen, richtig? So weit kommt der ISP ja erst gar nicht.

LG

Fipsi

Fipsi:
...
Der Reset-impuls kommt doch erst am Ende vom flashen, richtig? So weit kommt der ISP ja erst gar nicht.
...

Wenn ich die Beschreibung des ISP Protokolls richtig verstehe, wird die Flaschsequenz durch einen Pegelwechsel von High nach Low vom Brenner eingeleitet und durch einen Wechsel von Low nach High beendet.

Hab grad mal zwei kleine Ausschnitte angehängt, die meiner Meinung nach als einzige nicht so ganz passen. Bei allen Atmega's das selbe.

LG

Fipsi

Sorry, das Meldungsprotokoll sagt mir leider nichts.
Ich habe keine Ahnung von dem was dort alles ausgeben wird und kann nicht deuten was da richtig und was falsch ist.

Wäre es viel Aufwand in deiner Schaltung mal C4 und R2 auszulöten und dann nochmal zu probieren?

Schau dir mal
http://www.atmel.com/Images/doc3593.pdf
an.

Dort die Punkte 2.2.3 ISP Start Sequence und 2.2.4 ISP Exit Sequence mit den zugehörigen Diagrammen und im besonderen das RST/ Signal.
Und dann unter 2.2.6 Timing Parameters die zugehörigen Zeiten

Gruß
Peter

So, R2 und C4 sind draußen, Ergebnis bleibt das selbe. Bootloader ging nicht drauf.

Hab mir das mal angeschaut.. tu mir mit Englisch zwar "ein bisschen" schwer^^, aber ich glaube, so ziemlich hab ich's verstanden.

LG

Fipsi

Fipsi:
So, R2 und C4 sind draußen, Ergebnis bleibt das selbe. Bootloader ging nicht drauf.

Sie wie combie in diesem Thread schon schrieb, ist die maximal nutzbare Programmiergeschwindigkeit abhängig davon, wie schnell der Controller taktet.

Ein mit 16 MHz Schwingquarz getakteter Controller kann mit einer viel höheren Geschwindigkeit programmiert werden als ein mit 1 MHz intern getakteter Controller.

Wenn Du mit der Programmiergeschwindigkeit außerhalb der Spezifikation bist und mit zu schnellem Brenner-Takt programmieren möchtest, kann es sein, dass es manchmal doch klappt, oft aber auch nicht.

Der Diamex-Brenner wird von der Arduino-IDE standardmäßig überhaupt nicht unterstützt.

Um damit etwas zu brennen, mußt Du entweder die "programmers.txt" Datei modifizieren und kannst dann den Brenner über die Arduino-IDE nutzen.

Oder Du mußt Dein Brennprogramm mit den richtigen Parametern/Einstellungen direkt aufrufen.

Welche der Möglichkeiten nutzt Du mit Deinem Diamex und wie genau machst Du das?