Chip-Erase tut nichts

[S. R. (svenska)]

Hi,

ich habe einen Atmega1284p auf eine Lochrasterplatine gepackt und 
programmiere den mit einem usbasp und avrdude. An sich kein Problem.

Vorhin habe ich eine Konstante geändert, neu geflasht und avrdude 
scheitert an der Verifikation, da wäre was falsch. Mein Programm lief 
aber. Also nur ein Chip-Erase gemacht - und das Programm lief trotzdem?!

Die Kommunikation mit dem Chip funktioniert, Signatur und Flash auslesen 
ist kein Problem. Chip-Erase dauert kurz, löscht aber den Flash nicht. 
Woran kann das liegen? Und warum so spontan?

Versorgung läuft über ein Steckernetzteil mit 7805 dahinter, 100nF an 
Vcc für jeden Chip, 16 MHz-Quarz.

Gruß,
svenska

[Pandur S. (jetztnicht)]

Dass die Verifikation scheitert ist wegen der Auslese Fuse ueblich. 
Dabei kommt nur das ungerade Byte zurueck. Nicht genug um auf Identitaet 
zu testen.

[S. R. (svenska)]

Ich habe im avrdude-Terminal weitergetestet:
"dump flash 0x100 0x100" liefert mir Daten;
"erase" dauert einen Momeent;
"dump flash 0x100 0x100" liefert exakt die gleichen Daten.

Irgendwie schlägt das Chip-Erase fehl, was natürlich dafür sorgt, dass 
ein neues Programm nicht geflasht werden kann.

Sapperlot W. schrieb:
> Dass die Verifikation scheitert ist wegen der Auslese Fuse
> ueblich.

Magst du das näher ausführen? Die Verifikation sollte ja nicht grundlos 
scheitern, sonst wäre sie sinnlos (dass sie evtl. nicht alle Fälle 
abfängt, ist ja hier belanglos).

[Chris F. (chfreund)]

Ist die Spannung von dem usbasp richtig eingestellt? Lassen sich andere 
µC damit programmieren?

[S. R. (svenska)]

Chris F. schrieb:
> Ist die Spannung von dem usbasp richtig eingestellt?
> Lassen sich andere µC damit programmieren?

Mit genau diesem usbasp hatte ich diesen AVR in dieser Schaltung 
mehrfach (bestimmt 20x) programmiert, bevor der Fehler auftrat.

[Stefan (Gast)]

Hi,

Hast du eventuell (aus versehen) die Lock-Bits gesetzt? Die schützen 
auch vor Verifikation und erneutem Programmieren, siehe Table 27-2 im 
Datenblatt.

Gruß,
Stefan

[S. R. (svenska)]

Nein, die Fuses habe ich nur einmalig gesetzt und danach nicht wieder 
angefasst. Davon abgesehen sollten die Lock-Bits nicht vor einem 
Chip-Erase schützen.

[Peter R. (pnu)]

Sprichst Du wirklich die richtige Adresse an? und nicht irgendeine 
andre?
Dann bleibt die Konstante unberührt und irgendwo anders, evtl im nicht 
benutzten Teil des Programmspeichers ändert sich etwas.

Vor Allem an die verschiedenen Adressierungsarten in 
Programmspeicherzugriff denken:

Einerseits nach Schritten des Programmcounters (je 16 bit), andrerseits 
nach Schritten des Z-Indexcounters (je 8 bit).

[S. R. (svenska)]

Peter R. schrieb:
> Sprichst Du wirklich die richtige Adresse an? und nicht irgendeine
> andre?

Äh? Ich erwarte, dass nach einem Chip-Erase (vor dem Flashen des neuen 
Programms) das Flash komplett auf 0xFF steht. Das ist nicht der Fall, 
aus welchem Grund auch immer.

Ich programmiere nicht in Assembler, und die Firmware selbst legt bisher 
auch nichts im Flash ab (also kein PROGMEM bzw. __flash).

[S. Landolt (Gast)]

Versorgungsspannung direkt am uC kontrolliert?

[S. R. (svenska)]

S. Landolt schrieb:
> Versorgungsspannung direkt am uC kontrolliert?

Werde ich tun, wenn ich wieder zuhause bin (also erst heute abend). 
Danke für den Hinweis.

[Dietrich L. (dietrichl)]

Hast Du den µC schon mal getauscht? Vielleicht ist er defekt - warum 
auch immer.

[S. R. (svenska)]

Dietrich L. schrieb:
> Hast Du den µC schon mal getauscht?

Kann ich nicht, weil ich keinen anderen 40-pinnigen AVR habe. :-(

[S. R. (svenska)]

Hallo,

bin die letzten Tage leider nicht dazu gekommen, am Projekt 
weiterzuarbeiten.

Habe einen anderen Programmer ausprobiert, gleiches Phänomen.
Am AVR liegen stabil 5V an, zwischen Vcc und GND liegen 100 nF.

Hier eine manuelle Sitzung mit avrdude:

$ avrdude -p m1284p -c usbasp -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9705 (probably m1284p)
avrdude> dump flash 0x200 0x40
>>> dump flash 0x200 0x40 
0200  8f 93 9f 93 ef 93 ff 93  80 91 56 01 90 e0 01 96  |..........V.....|
0210  20 91 c6 00 30 91 57 01  38 17 41 f0 80 93 56 01  | ...0.W.8.A...V.|
0220  e0 91 56 01 f0 e0 e8 5a  fe 4f 20 83 ff 91 ef 91  |..V....Z.O .....|
0230  9f 91 8f 91 3f 91 2f 91  0f 90 0b be 0f 90 0f be  |....?./... .....|

avrdude> erase
>>> erase 
avrdude: erasing chip
avrdude> dump flash 0x200 0x40
>>> dump flash 0x200 0x40 
0200  8f 93 9f 93 ef 93 ff 93  80 91 56 01 90 e0 01 96  |..........V.....|
0210  20 91 c6 00 30 91 57 01  38 17 41 f0 80 93 56 01  | ...0.W.8.A...V.|
0220  e0 91 56 01 f0 e0 e8 5a  fe 4f 20 83 ff 91 ef 91  |..V....Z.O .....|
0230  9f 91 8f 91 3f 91 2f 91  0f 90 0b be 0f 90 0f be  |....?./... .....|

avrdude> quit
>>> quit 

avrdude: safemode: Fuses OK (E:FC, H:D9, L:FF)

avrdude done.  Thank you.

Die Fuses sehen an sich auch gut aus. Kann das sein, dass der Chip dahin 
ist - nur wie passiert das?

Gruß

[S. R. (svenska)]

Die Fuses lassen sich auch nicht ändern, obwohl die Kommunikation noch 
funktioniert. Seltsam.

[Jobst M. (jobstens-de)]

S. R. schrieb:
> zwischen Vcc und GND liegen 100 nF.

Nur dort? Einer?

Gruß
Jobst

[Chris F. (chfreund)]

Es liegt wahrscheinlich nicht an den Kondensatoren.

Probier mal den ISP-Takt runterzuschrauben und zusätzlich mit "-i 20" 
ein wenig Verzögerung reinzubringen. Ist aber nur Gestocher im Tümpel, 
grundsätzlich sieht das alles okay aus.

Hast Du irgendwie die Möglichkeit diesen Programmer mit einem anderen 
AVR zu testen? Irgendeinen DIP auf dem Breadboard? Echt garnichts mehr 
in der Krabbelkiste?

[Jobst M. (jobstens-de)]

Chris F. schrieb:
> Es liegt wahrscheinlich nicht an den Kondensatoren.

Ich würde dennoch zunächst diese Möglichkeit ausschließen.


> Probier mal den ISP-Takt runterzuschrauben und zusätzlich mit "-i 20"
> ein wenig Verzögerung reinzubringen.

Das wird sicherlich rein gar nichts bringen. Der Löschbefehl ist eine 
Folge aus 4 Bytes (0xAC 0x80 0x00 0x00). Maximal 9ms später sind die 
Daten normaler weise weg.


S. R. schrieb:
> Mit genau diesem usbasp hatte ich diesen AVR in dieser Schaltung
> mehrfach (bestimmt 20x) programmiert, bevor der Fehler auftrat.

Ich vermute hier aber dennoch irgendwie den Tod des Chips. Ich hatte 
schon ähnliche Fälle. Vielleicht ESD!?


Gruß
Jobst

[S. R. (svenska)]

Jobst M. schrieb:
>> zwischen Vcc und GND liegen 100 nF.
> Nur dort? Einer?

Direkt am 7805 ist auch noch einer, aber daran liegt es sicher nicht. 
Hat ja vorher funktioniert...

Chris F. schrieb:
> Hast Du irgendwie die Möglichkeit diesen Programmer mit einem anderen
> AVR zu testen?

Für einen Test mit einem anderen AVR müsste ich jetzt erst was aufbauen, 
aber ich habe ja zwei verschiedene Programmer probiert. Die 
Kommunikation funktioniert mit beiden.

Jobst M. schrieb:
> Ich vermute hier aber dennoch irgendwie den Tod des Chips. Ich hatte
> schon ähnliche Fälle. Vielleicht ESD!?

Möglich. Naja, verbuche ich das als Lehrgeld und gut ist. Ein seltsames 
Verhalten ist es trotzdem.

In jedem Fall danke für die Hinweise.

[Jobst M. (jobstens-de)]

S. R. schrieb:
> Hat ja vorher funktioniert...

Bauteile gehen ja auch nicht kaputt ...
An den ATm1284 gehören mindestens 3x 100nF

Gruß
Jobst

[S. R. (svenska)]

Jobst M. schrieb:
> An den ATm1284 gehören mindestens 3x 100nF

Am 7805 sind zwei davon, am AVR einer, am DRAM ebenfalls einer. Für eine 
kleine Lochrasterplatine mit Kupferlackdraht ganz angemessen. :-)

Wenn ich ein bisschen Langeweile habe, stecke ich den AVR mal auf ein 
Breadboard und schaue, was passiert; ansonsten ziehe ich weiter. Gibt 
noch genug offene Projekte.

[Jobst M. (jobstens-de)]

S. R. schrieb:
> Jobst M. schrieb:
>> An den ATm1284 gehören mindestens 3x 100nF
>
> Am 7805 sind zwei davon, am AVR einer

Kondensatorsharing wär mir neu. Der 7805 braucht seine zwei eigenen. 
(Bzw. das, was im DB des jeweiligen Herstellers steht.)

Ist das wirklich Deine ernsthafte Herangehensweise? =-O


Gruß
Jobst

[S. R. (svenska)]

Jobst M. schrieb:
> Ist das wirklich Deine ernsthafte Herangehensweise? =-O

Was ist denn jetzt das Problem? Ich habe ein 5V-Rail, und da hängen 3x 
100nF Kondensatoren dran, an jedem Chip einer.

Korrektur: Am AVR hängen sogar zwei Kondensatoren, zwischen Vcc-GND und 
AVcc-GND. Damit sind auf der Platine insgesamt sogar fünf verlötet. ;-)

Dass ein m1284p drei Kondensatoren braucht, war mir schlicht nicht 
bekannt. Vorhanden sind jedenfalls mehr als bei den meisten, die hier 
anfragen. :-)

[Chris F. (chfreund)]

Ich hatte bei einem 644V-au@8MHz 5 oder 6 0805er-Kerkos drumherum, der 
ist kompatibel und aus der gleichen Serie wie dieser 1284, allerdings 
hat der -p (DIP) nur 2xGND und 1xVCC. Bei 16MHz und einer unbekannten 
Schaltung schadet das nichts an jeden GND-Pin ca. 47nF so nah wie es 
geht an das Pad zu packen.

Fazit: 3 Stück 100nF tht-Kerkos direkt an das 40pin-DIP-Monster gelötet 
hier sind total okay. :-)



S. R. schrieb:
> Am 7805 sind zwei davon, am AVR einer,

Jobst M. schrieb:
> Ich würde dennoch zunächst diese Möglichkeit ausschließen.

Ja. Ich zweifele das zwar kategorisch an, dass das programmieren so 
empfindlich ist, aber der Aufbau sollte schon stimmen. Daher nehme ich 
alles zu den Kondensatoren zurück und behaupte das Gegenteil.