AVR Dragon und AVR Studio EEPROM Limit?

Gast #2322731
Lesenswert?

AVR Studio 4.18
ATmega 16
AVR Dragon
WinAVR-20100110
Verbindung über JTAG

Hallo Leute,

ich habe neuerdings ein seltsames Problem.
Der genutzte EEPROM-Speicher meines Projekts ist jetzt
EEPROM:      421 bytes (82.2% Full)
(.eeprom)

Nun bricht AVR-Studio beim Debugger-Start (laden Programm und EEPROM)
mit folgender Meldung ab:

AVR Dragon: Time out while waiting for response from emulator...
Coordinator: Error when writing memory contents to the debug platform.
Coordinator: Error loading object file.

Wenn ich den genutzten EEPROM-Platz verkleinere:
EEPROM:      339 bytes (66.2% Full)
(.eeprom)
läuft alles prima.

Das Verhindern des EEPROM-Schreibens über Fuse EESAVE bringt auch keine 
Verbesserung.

Gibt es irgendeine Beschränkung der maximal nutzbaren EEPROM-Größe im 
Dragon/AVR Studio?
Gibt es einen Timeout beim Speicher-Laden der ggf. jetzt überschritten 
wird?

Gruß

Danni
Gast #2323729
Lesenswert?

Nachtrag. Kann es sein, das sich ein defekter Prozessor so ankündigt? 
Mittlerweile kann ich ihn überhaupt nicht mehr connecten. Weder über 
JTAG (Dragon) noch über ISP (STK500). Das Program läuft aber stand alone 
(ohne Debugger) komischerweise noch problemlos ab.
Bei einem Test mit einem ATmega8515 (kleines Demo-Programm) läuft alles 
prima. ISP download etc. klappt.
Könnte natürlich auch der Sockel oder ein Problem mit dem Board sein.

Ich habe jetzt mal einen neuen ATmega16 bestellt, in der Hoffnung, daß 
er zu oft programiert wurde und deshalb ausgefallen ist. Ich kann nicht 
genau sagen wie oft der schon gelöscht und überprogrammiert wurde. Min 
150 mal aber sicher.
Na vielleicht hat ja noch Jemand eine andere Idee.

Gruß

Danni
Gast #2323734
Lesenswert?

Hi

>Ich habe jetzt mal einen neuen ATmega16 bestellt, in der Hoffnung, daß
>er zu oft programiert wurde und deshalb ausgefallen ist. Ich kann nicht
>genau sagen wie oft der schon gelöscht und überprogrammiert wurde. Min
>150 mal aber sicher.

Da lächelt den AVR nur drüber. Sieh im Datenblatt, 1.Seite, nach. Aber 
solche Fehler können auch bei mangelhafter Stromversorgung auftreten.

MfG Spess
Gast #2323755
Lesenswert?

@Spess53
Ja, das kann eigentlich nicht sein. Auch wenn ich den Prozessor "geerbt" 
habe und er vorher min. auch schon 150 mal beschrieben wurde.

Auffällig ist, daß er sehr leicht in und aus dem Sockel geht. Die 
Kontakte sind schon ziemlich nach innen gebogen. Der andere 8515 geht 
dagegen ohne Werkzeug gar nicht aus dem Sockel. Trotzdem komisch, daß 
sonst alles läuft. Wenn es ein Kontaktproblem ist dann sollte es ja 
nicht sowohl über JTAG als auch ISP Probleme geben. Zumal ich ihn schon 
mehrmals rein und rausgenommen habe.
Ich warte mal ab ob und wie es mit dem neuen Prozessor klappt.
Gast #2323806
Lesenswert?

hey..

ich weiß nicht ob du das schon verifiziert hast, aber ich hab mich durch 
irgendein rumgefrickel im AVR Studio auch schon mal auf ne ähnliche art 
ausgesperrt.. interessanterweise hatte ich scheinbar irgendwie den AVR 
auf factory settings zurückgestellt.. sprich: ISP frequenz aufs minimum 
gesenkt, fuses gelesen und geschrieben, ISP frequenz wieder rauf, und 
alles war schön..

vielleicht hilfts ja.

mfg
Gast #2326575
Lesenswert?

Der Mist ist, daß ich nicht mal mehr die Signatur des Prozessors 
auslesen, geschweige denn die Fuses lesen oder schreiben kann.
Was bedeutet eigentlich "...Would you like to retry with external reset 
enabled?
Über JTAG wird der Reset doch vom Dragon über die separate Reset-Leitung 
gesteuert.

Ich kann nicht mal die ISP-Frequenz setzten oder lesen. Antwort immer 
"Getting ISP frequency parameters.. FAILED".
Wie gesagt, das alles geht mit einem anderen Prozessor in einem anderen 
Slot des STK500 problemlos.

Das ganze Drama begann mit dem o.g. EEPROM-Problem.
In meiner Not habe ich dann auf AVR Studio 4.18 Build 716 geupdated. 
Kann ja nicht schaden. Evtl. ist der EEPROM-Bug in der Studio-SW 
begründet, dachte ich.
Dann hab ich noch die AVR-Toolchain installiert anstatt des bisherigen 
WinAvr. Motto: "Jetzt wächst zusammen was zusammen gehört.
Brachte beim Compilieren sogar ein paar Bytes weniger Code.
Irgendwann war dann (ob dadurch weiß ich nicht) der Controller garnicht 
mehr ansprechbar. Also typische Verschlimmbesserung.
Jetzt bin ich wieder zurück auf die WinAvr. Brachte aber auch keine 
Veränderung.
Gast #2327749
Lesenswert?

Nur um den Monolog zu beenden. Neuer Prozessor ist da und es geht alles 
wieder! War offenbar (zum Glück) nur der uP defekt.

Bemerkenswert war aber, daß sich das Problem durch ein nur noch 
teilweise beschreibbares EEPROM ankündigte.

Egal, vielleicht hilft diese Info mal einem weiter.
Trotzdem Danke für die Antworten.

Gruß

Danni
Gast #2327766
Lesenswert?

Danni schrieb:

> @dunno:
> Wo kann man auf die factory settings zurücksetzten?


wenn ich das mal wüsste...

wie gesagt, ich hatte die selben symptome wie du, irgendwas 
rumexperimentiert, auf bekam ich mecker wegen dem eeprom beim 
programmieren, konnnte plötzlich auch nicht mehr flashen, µC ansonsten 
funktionsfähig..
das mit dem reset bekomm ich übrigens hin und wieder mal, target vom 
netz nehmen und wieder hin bringt es meist..

ich glaub ich hab dann von jtag auf isp gewechselt, den isp takt vom 
dragon reduziert, und konnte meine fuses lesen.. und, wie durch ein 
wunder war clkdiv gesetzt, interner takt, jtag deaktiviert..
also die fuses wieder entsprechend gesetzt, und bumm- lief.

mfg

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren