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
Dass die Verifikation scheitert ist wegen der Auslese Fuse ueblich. Dabei kommt nur das ungerade Byte zurueck. Nicht genug um auf Identitaet zu testen.
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).
Ist die Spannung von dem usbasp richtig eingestellt? Lassen sich andere µC damit programmieren?
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.
Gast
#5048082
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
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.
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).
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).
Gast
#5048153
Versorgungsspannung direkt am uC kontrolliert?
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.
Hast Du den µC schon mal getauscht? Vielleicht ist er defekt - warum auch immer.
Dietrich L. schrieb: > Hast Du den µC schon mal getauscht? Kann ich nicht, weil ich keinen anderen 40-pinnigen AVR habe. :-(
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:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
Die Fuses sehen an sich auch gut aus. Kann das sein, dass der Chip dahin ist - nur wie passiert das? Gruß
Die Fuses lassen sich auch nicht ändern, obwohl die Kommunikation noch funktioniert. Seltsam.
S. R. schrieb: > zwischen Vcc und GND liegen 100 nF. Nur dort? Einer? Gruß Jobst
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?
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
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.
S. R. schrieb: > Hat ja vorher funktioniert... Bauteile gehen ja auch nicht kaputt ... An den ATm1284 gehören mindestens 3x 100nF Gruß Jobst
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.
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
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. :-)
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.