Forum: Mikrocontroller und Digitale Elektronik ATMega64 beschreiben


von Omou (Gast)


Lesenswert?

Hallo an die Foren-Gemeinde,

ich habe folgendes kleines Problem.
Wenn ich versuche meinen ATMega64 zu beschreiben, ob via SPI oder JTAG 
so klappt das nicht. Immer eine Adresse ist nicht gleich und so muss ich 
erst den Chip löschen und dann beschreiben, dann geht alles.

Sollte ja nicht das Problem sein gibt es im Studio ja ein Hacken ( vorm 
programmieren device löschen ).

Doch habe ich den Fehler auch beim Bootlader den ich geschrieben habe 
und da ist es nicht das was es sein sollte. Wenn ich später eine 
Änderung via Bootloader einspielen möchte klappt das halt aus dem 
gleichen Grund nicht.

Liegt dieses nun am ATMega64?
Würde der Umstand helfen wenn ich mit dem Bootloader vorab alles auf FF 
schreibe?

Ein umstand aber das würde ich in kauf nehmen.

Doch eigentlich wollte ich das nicht weil normal kann das doch nicht 
sein oder?

Besten Dank schon mal für die Antworten die hoffentlich kommen.

Ach ja... sollte ich eventuell mal auf einen anderen ATMega umsteigen. 
ISt der ATMega noch zukunfssicher?

von Oliver (Gast)


Lesenswert?

Omou schrieb:
> Doch habe ich den Fehler auch beim Bootlader den ich geschrieben habe

Äh, ja, und?

Wenn du den bootloader selber geschrieben hast, dann weiß niemand außer 
dir, was der genau macht, warum der Speicherzellen vergleicht, und wann 
er warum dabei meckert. Also lies einfach mal die Doku zu deinem 
bootloader...

Oliver

von Omou (Gast)


Lesenswert?

Ich kenne meinen Bootloader ( habe keine Doku dazu :-) )läuft aber schon 
lange auch so auf anderen Mega's.

Es wird nicht am Booloader liegen, weil wie getippt er auf anderen z.b. 
ATMega88 läuft und das Problem ja auch ohne Bootloader via SPI und JTag 
da ist.

Ich muss immer erst das Device löschen. Momentan habe ich gar kein 
Bootloader drauf und immer knallt es wenn ich vorab den Chip nicht 
lösche.

von Dietrich L. (dietrichl)


Lesenswert?

Hast Du auch mal ein anderes Exemplar probiert? Vielleicht hat der ja 
einen Macken...

von Omou (Gast)


Lesenswert?

Genau das ist meine Frage, ob das sein könnte.
Ich habe leider kein Sockel und so einen auf eine Adapter Platine 
aufgelötet.

Pins über Jumperleitungen weg geführt auf ein Steckbrett.

Ich müsste nun einen anderen Mega auf ein andere Adapter-Platine 
auflöten. Alles abzuppeln und neu anstecken... Wow was für eine Arbeit 
um eventuell nachher das gleiche Resultat zu bekommen.

Und was mach ich wenn der andere auch ein Schlag hat...
Was wird gemacht wenn ich vorab Erase Chip setze. Nur der 
Speicherbereich vorab mit FF gefüllt?

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

Omou schrieb:
> Ich muss immer erst das Device löschen. Momentan habe ich gar kein
> Bootloader drauf und immer knallt es wenn ich vorab den Chip nicht
> lösche.

 Dann prüfe mal LB1 und LB2 bits.

von uwe (Gast)


Lesenswert?

> und so muss ich erst den Chip löschen und dann beschreiben, dann geht alle
Ja das ist normal, so ist das beim flash. Man muß erst mal ein Erase 
Vorgang machen(der alle bits wieder auf 1 setzt). Denn man man kann beim 
schreiben die Bits nur auf 0 setzen. Man kann 0b11110000 nicht mit einem 
schreiben von 0b11111111 wieder auf 0b11111111 zurücksetzen. Das geht 
nur bei einem EEPROM nicht bei einem Flash. man muß jedoch nicht den 
ganzen Flash erasen, denn dieser ist deshalb in Pages unterteilt, die 
man einzeln erasen kann. Dies macht man im Bootloader mit einem "page 
erase" wobei in ZH dann die page nummer steht die man erasen will.
ab Seite 282 im Datenblatt:
http://www.atmel.com/images/atmel-2490-8-bit-avr-microcontroller-atmega64-l_datasheet.pdf

von uwe (Gast)


Lesenswert?

Im ISp programmiermodus muß man halt das Häkchen bei "erase before 
write" (löschen vorm programmieren) setzen.

von Omou (Gast)


Lesenswert?

Nun das mach ich in meinem BootLoader ja
1
; Page löschen
2
    ldi   SPMKommando, (1<<PGERS) | (1<<SPMEN)
3
    rcall Start_SPM

davor lade ich natürlich in z den Zeiger auf das Flash.
1
Start_SPM:
2
; Läuft noch ein SPM? Ja? Warte bis fertig.
3
Wait_spm:
4
  lds   r17, SPMCSR
5
  sbrc  r17, SPMEN
6
        rjmp  Wait_spm
7
8
; Läuft noch das EEPROM schreiben? Ja? Warte bis fertig.
9
Wait_ee:
10
  sbic  EECR, EEWE
11
        rjmp  Wait_ee
12
13
; SPM starten
14
    sts   SPMCSR, SPMKommando
15
    spm
16
ret

also ganz so wie im Datemblatt beschrieben.

von uwe (Gast)


Lesenswert?

Interupts deaktiviert?! Sonst könnte dir ein Interupt den Ablauf 
versauen.

von uwe (Gast)


Lesenswert?

Watchdog ist auch deaktiviert?

von Omou (Gast)


Lesenswert?

Macht das Studio nicht einen Reset so das alles interrupt's aus sind. 
Beim BootLoader springe ich auch nur beim Start des µC in die Routine.

von Omou (Gast)


Lesenswert?

Wie bzw. was nun das Studio genau macht bei der Option Chip vorher 
löschen ist hier keinem Bekannt?

von holger (Gast)


Lesenswert?

>Wie bzw. was nun das Studio genau macht bei der Option Chip vorher
>löschen ist hier keinem Bekannt?

Es löscht das gesamte Flash inklusive Bootloader.

von Omou (Gast)


Lesenswert?

Das er das Flash löscht ist klar, wie macht er es?

von spess53 (Gast)


Lesenswert?

Hi

>Das er das Flash löscht ist klar, wie macht er es?

Es gibt für jeden Programmiermode ( parallel, seriell und JTAG) einen 
Befehl
Chip Erase. Und der wird einfach an den AVR geschickt.

MfG Spess

von Omou (Gast)


Lesenswert?

Danke für die Info. Gerade nach Deinem Tipp im Datenblatt auch gefunden. 
Schitt damit werde ich also auch nicht weiter kommen da man dieses nicht 
im BootLoader machen kann.

Werde wohl doch nicht darum kommen ein zweiten auf zu bauen um zu sehen 
ob es am Chip liegt.

von Oliver (Gast)


Lesenswert?

Ich versteh das Problem immer noch nicht.

Wer stellt bei Programmierung über den bootloader fest, daß da ein Byte 
nicht stimmt? Dein bootloader oder das Studio? Läuft das Programm 
trotzdem?
Und welches Byte stimmt da nicht? Ein Byte innerhalb des Programms, oder 
eins, was hinter dem Programmende vorkommt?

Oliver

von Omou (Gast)


Lesenswert?

Ich habe nun ein anderen ATMega64 genommen und das gleiche Phänomen 
tritt auf.

Immer 0x0002 im Flash ist falsch 0x20 ( 0xFF )

Den BootLoader habe ich erst mal raus gelassen.

Der ATMega64 läuft auf 14.7456Mhz.

Mich nervt es halt das ich jedes mal das EEprom wieder herstellen darf ( 
Erase Device löscht ja auch das EEprom ) und auch den BootLoader ( 
sollte ich Ihn mal nicht weglassen ) zuerst wieder drauf machen muss.

Das es über den BootLoader auch nicht geht, könnte ein anderes Problem 
sein, deswegen erst mal raus. Aber wie getippt geht es auch nicht über 
das Studio ( ob 4 oder 6 ) bzw. nur mit vorab komplett löschen.

von spess53 (Gast)


Lesenswert?

Hi

>Mich nervt es halt das ich jedes mal das EEprom wieder herstellen darf (
>Erase Device löscht ja auch das EEprom ) ...

EESAVE Fuse setzen.

MfG Spess

von Omou (Gast)


Lesenswert?

Schon mal ein klasse Tipp Danke.

Nun bin ich aber noch nicht davor verschont den BootLoader Bereich 
geschützt zu haben oder?

von spess53 (Gast)


Lesenswert?

Hi

>Nun bin ich aber noch nicht davor verschont den BootLoader Bereich
>geschützt zu haben oder?

Was willst du eigentlich? ISP oder Bootloader?

MfG Spess

von Omou (Gast)


Lesenswert?

Endstadium sollte der BootLoader natürlich sein. Doch bekomme ich über 
Ihn das Programm nur drauf wenn der Chip vorher leer ist. Also Chip 
Erase... BottLoader drauf und alles ist OK beim Flashen über den 
BootLOader.

Doch ein Update über den BootLoader geht nicht, wegen besagten Fehler.
Also habe ich das via Studio ( 4 und 6 ) versucht, auch keine Chance. 
Erst wenn ich den Chip lösche geht es.

Um den Fehler einzugrenzen habe ich nun den BootLoader erst mal runter 
geschmissen. und suche jetzt nach der Ursache.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.