Flash von ATMEGA 128 nach Program/Verify leer (keine Lockbits gesetzt)

[gernotmueller]

Hallo,

hoffentlich kann mir jemand bei meinem Problem helfen.
Und zwar programmiere ich einen ATMEGA128 mit einem Hexfile, das einen
Bootloader und Application beinhaltet. Beides wird also gleichzeitig
programmiert. Lockbits sind keine gesetzt, somit alles frei
programmierbar. Alle Fuse und Lockbits sind richtig eingestellt, da
diese Einstellungen in der Produktion in meiner Firma bei 50+ Stück auch
so funktioniert hat. Bei 7 Stück allerdings nicht.

Nun ist das Problem, dass nach einem Programmieren und anschließendem
Verify scheinbar alles programmiert ist. Liest man nun das Flash nochmal
aus, ist es bis auf den Bootloader leer. Dies habe ich schon mit 3
verschiedenen Programmiertools und Programmern probiert, mit dem selben
Ergebnis. Programmiert man nur die Application ohne Bootloader
funktioniert das Schreiben ins Flash, da beim Lesen alles so drinsteht
wie es sein soll und die Applikation läuft.

Was kann das Problem sein?? Hatte irgend jemand schon mal so eine
Situation. Der ATMEGA wurde auch schon getauscht, und dennoch das selbe
Problem.

Danke schon mal für die Hilfe!

 

[maik]

Hallo Gernot,

welchen Programmierer nutzt du?
Hast du schon mal versucht langsamer zu übertragen?

 

[gernotmueller]

Ja hab schon folgende Programmer probiert:
Kanda AVR USB zusammen mit AVRUSB Software
AVR Dragon und AVR ISP Mk2 Programmer mit Code Blaster und AVR Studio Software.

Daweil nur ISP probiert, noch kein JTAG. Geschwindigkeit hab ich auch schon auf 125kHz gedrosselt.

 

[Dirk]

Hallo Gernot,

zunächst macht es bezüglich der Programmierung keinen Unterschied, ob du Bootloader und/oder Applikation programmierst, da es sich bei dem ATmega um den selben Flash-Bereich handelt. Unterschiede gibt es nur bei den Lockbits, die wirken auf die unterschiedlichen Speicherbereiche des Programmspeichers.

Bist du dir sicher, dass du die Lockbits wirklich nicht programmiert hast, werden die eventuell nach Programmierung und (erfolgreichem) Verify automatisch programmiert? Dies würde zumindest erklären, warum ein nachträgliches Verify oder Auslesen des Speichers nicht erfolgreich ist, bzw. dass du leere Bereiche liest.

Schon sehr komisch. Zumal es anscheinend mal funktioniert und mal nicht

Was mich interessieren würde, wie wird das Hexfile erzeugt?

Hast du dir das Hexfile schon einmal angesehen? Du kannst hierfür zum Beispiel unseren AVR-HexViewer verwenden, dieser zeigt schön die Speicherbelegung des AVR an.

Grüße,
Dirk

 

[gernotmueller]

Hallo Dirk,

ja ich weiß, dass es keinen Unterschied machen sollte. Dennoch macht es anscheinend einen.

Ja habe die Lockbits zigmal manuell ausgelesen, gesetzt, verified. Und das mit 3 verschiedenen Programmen (Code Blaster, AVR Studio, AVRUSB). Immer mit demselben Ergebnis, dass die Lockbits nicht gesetzt sind. Alles offen. Auch beim automatischen Programmieren setze ich die Lockbits nicht.

Zum Hexfile:
Dies habe ich von unserer Produktion bekommen. Jedoch kann man sich das leicht selbst machen. Das Applications Hexfile wird hergenommen und der END of File record wird wegenommen. Danach wird einfach das Bootloader Hexfile drangehängt. Dort ist dann auch der end of file record wieder drinnen. AVRUSB prüft auch das Hexfile beim Laden. Wenn da was nicht stimmt schreit der gleich. Hatte nämlich diese Situation schon mal.

Den Hex Viewer hab ich mir schon runtergeladen und mal das Hexfile angesehen. Sieht genaus so aus, wie es sein soll. Bootloader ist im oberen Bereich ab 1F000. Application fängt bei Adresse 00000 an.

by the way --- tolles program der hex viewer

hab nun mal eine mail an den atmel support geschickt, vielleicht haben die eine idee

 

[Markus]

Hallo zusammen,
hallo gernotmueller,

wie genau programmierst Du den ATmega128? Hast Du Dir einen Programmieradapter gebaut in dem Du den Mega ISP'st und nur den Mega tauschst oder proggst Du direkt in der Zielhardware?

Wenn Zielhardware .... wie genau sieht Deine Reset-Beschaltung aus? Ich hatte mal ein ähnliches Problem und da lag es an der Tolleranz der Bauelemente für den Reset. Der ISP Prommer zieht an der Reset-Leitung um den Mega in den Programmiermode zu bekommen. Durch die Tolleranz der Bauteile hat er das nicht immer geschafft. Gesehen hat man das nur mit dem Oszi.

Zunächst würde ich mit das nochmal zur Sicherheit anschauen, ggf. mit Hilfe von Oszi um es als Fehlerquelle auszuschließen.

Grüße,
Markus

 

[gernotmueller]

Hallo Zusammen,

Habe die letzten Tage intensiv getestet und den Fehlerherd gefunden. Ganz kann ich mirs nicht erklären, aber zumindest gehts nun.

Also, als erstes habe ich ein kleines Demo Board gebastelt um die scheinbar defekten ATMEGA128 dort mal zu programmieren. Habe dabei nur die nötigen Pins angeschlossen und sonst nichts weiter. Siehe da, es ging auf einmal.

Daher war mein Schluss, irgendetwas in der Schaltung verursacht den Fehler und lässt mich den ATMEGA nicht 100% programmieren. Da es nur ein Bauteil gibt, das die Pins der Programmierschnittstelle teilt, habe ich mir das ATMEL Datenflash (AT45DB161) angesehen. Dieses hängt mit der SPI Schnittstelle an dem ATMEGA128 dran. Das Datenflash teilt den SCK Pin mit der ISP Schnittstelle.

Nach dem Entfernen des Datenflashs aus einer defekten Karte funktionierte das Programmieren auf einmal wunderbar. Daher ist das Datenflash das Problem. Der einzige Pin der wirklich zw. Datenflash und Programmierschnittstelle geteilt wird, ist der SCK Clock der SPI. Dies ist aber nur ein Eingang für das Datenflash. Habe dann das Datenflash wieder an den ATMEGA angeschlossen, außer den SCK Pin. Siehe da, der ATMEGA ging noch immer toll zu programmieren. Dann hab ich den SCK Pin kontaktiert und es ging nicht mehr.

Mittles Logic Analyzer hab ich mir mal die Pins der Programmierschnittstelle angesehen und vor allem den SCK Pin. Der Clock kommt allerdings wunderbar, egal ob der SCK Pin am Datenflash hängt oder nicht.

Nachdem ich das Datenflash als Fehlerherd identifiziert hatte, habe ich nun ein neues Datenflash eingebaut und alle Pins kontaktiert. Siehe da nun gehts auf mit Datenflash. Daher dürfte bei den defekten Boards das Datenflash kaputt sein. Warum der SCK Pin dennoch schön hin und her toggelt versteh ich aber nicht. Also den eigentlichen Fehler hab ich nicht gefunden.

Vielleicht fällt euch ja ein, was den Fehler wirklich verursacht hat. Ansonsten ist es vielleicht eine interessante Geschichte, von der man was lernen kann.

lg
Gernot

 

[dino03]

Hallo Gernot,

Da es nur ein Bauteil gibt, das die Pins der Programmierschnittstelle teilt, habe ich mir das ATMEL Datenflash (AT45DB161) angesehen. Dieses hängt mit der SPI Schnittstelle an dem ATMEGA128 dran. Das Datenflash teilt den SCK Pin mit der ISP Schnittstelle.

ist die ISP-Beschaltung mit dem Dataflash so wie bei Atmel in AppNote ?
Also die ISP-Schnittstelle direkt am Mega128 und die andere Hardware über
1k-Widerstände an den ISP-Pins des Mega128 ? Evtl kommt da doch eine
Beeinflussung zustande. Kann ja sein das das Timing dadurch nicht sauber
ist.

Ich habe mal nen normalen Parallelport-Progger und auch den AVR-ISP-mk2
mit externer Beschaltung gequält und getestet wann sie die Löffel streichen.
Maximale Belastungen am ISP-Port ...Maximale Belastungen am ISP-Port ...
In dem Thread hab ich mal einiges ausgetestet

Gruß
Dino