ATMEGA 644P 20PU

[linux_80]

Wo steht das ?
bei Willa's Posts gibst zB. kein P.
Alles oberhalb ist ja schon erledigt.

@Willa,
welcher 644er ist es denn nun genau, mit oder ohne P ?
In der Configdatei steht kein P.

[Besserwessi]

Wenn es nur das Problem mit dem 644P ist, kann man sich wohl damit behelfen die gelesene CHip ID zu ignorieren. Das sollte zumindestens dann gehen wenn man die extra Funktionen/Register des 644P nicht braucht.

[Willa]

Hallo!
Danke erstmal für eure Posts. Ich hatte bei Reichelt einen Atmega644-20PU bestellt und auf dem Chip steht nun Atmega644P-20PU. Mit Bascom 1.11.9.1 gings noch nicht, dann werde ich mal 9.2 probieren... Die Chip ID ist übrigens IE960A

Viele Grüße,
William

[Besserwessi]

Der Mega644P ist Aufwärtskompatibel, zum Mega644. Mit Update ist sicher eleganter, ab sonst sollte das ignorieren der ChipID auch gehen als Übergangslösung.

[raf]

Hallo Leute,
ihc habe einiges in der letzten Zeit ausprobiert jedoch keine Lösung gefunden.
Egal welches Tool ich zum flashen nutze Bascom / Burn O Mat o.ä. nix funktioniert richtig.
Also schliesse ich erstmal ein Problem mit der SOFTWARe aus.

Gruß
Ralf

[Willa]

Also bei mir hats kurz funktioniert und der 644p wurde erkannt. Dann habe ich die Fusebits "divide clock by 8", "enable JTAG" ausgeschaltet und die clock source auf external oscillator gestellt. danach wurde der µC nicht mehr erkannt, die Chip ID ist nun FFFFFF.... (es hängt ein 20MHz Oszillator an XTAL1). Kann man da noch was machen oder sollte ich den ganzen Kram aus dem Fenster schmeißen und nen ATmega32 benutzen?

[raf]

@Willa,
Also grundsätzlich können AVR`s wo FUSEBITS verstellt wurden wieder belebt werden.
Schau mal hier.
http://www.der-hammer.info/hvprog/
ein Beispiel. Habe ich jedoch noch nicht nachgebaut. Steht bei mir jedoch auf der Liste.

Bei mir ist es mit dem 644P jedoch so, dass ich garnicht weiter komme. Ich bekomme immer diese Meldung.
Could not identify chip with ID:FFFFFF

Und das hängt meiner Meinung nach nicht mit dem Bascom zusammen, andere Prog Programme melden das gleiche.

Gruß
Ralf

[Besserwessi]

external oscillator heißt überssetzt ins Deutsche eine (kompletter) externer Oszillator. Ein Quarz ist aber keine Oszillator, sondern nur eine Resonator (engl. resonator). Also sollte man die Fuses auch auf external resoantor setzen.

Um den Controller mit den Falsch gesetzten Fuses weiter umzuprogrammieren, muß man einen externen Takt an XTAL1 anlegen (z.B. 1 MHz Rechteck). Dann geht auch das Programmieren wieder.

[raf]

Also noch mal ein test durchgeführt.
Nachdem ich die Optionen für avrdrude -D -F eingestellt habe wurde folgendes ausgegeben:
E:\Programme\WinAVR\bin\avrdude.exe -q -u -C E:\Programme\WinAVR\bin\avrdude.conf -p m644P -P lpt1 -c pony-stk200 -E noreset,novcc -D -F -U efuse:r:d:\TEMP\efuse51829.hex:r -U hfuse:r:d:\TEMP\hfuse51828.hex:r -U lfuse:r:d:\TEMP\lfuse51827.hex:r

avrdude.exe: AVR device not responding
avrdude.exe: initialization failed, rc=-1
avrdude.exe: AVR device initialized and ready to accept instructions
avrdude.exe: Device signature = 0xffffff
avrdude.exe: Yikes! Invalid device signature.
avrdude.exe: Expected signature for ATMEGA644P is 1E 96 0A
avrdude.exe: reading efuse memory:
avrdude.exe: writing output file "d:\TEMP\efuse51829.hex"
avrdude.exe: reading hfuse memory:
avrdude.exe: writing output file "d:\TEMP\hfuse51828.hex"
avrdude.exe: reading lfuse memory:
avrdude.exe: writing output file "d:\TEMP\lfuse51827.hex"

avrdude.exe done. Thank you.


OK Hört sich nicht so schlecht an. Also kleines Progrämmchen geschrieben und schreiben.
Schon wieder eine Error Meldung
E:\Programme\WinAVR\bin\avrdude.exe -q -u -C E:\Programme\WinAVR\bin\avrdude.conf -p m644P -P lpt1 -c pony-stk200 -E noreset,novcc -D -F -U flash:w:G:\Programmierung\Roboter\eigene\Mega644P\ main.hex:a

avrdude.exe: AVR device not responding
avrdude.exe: initialization failed, rc=-1
avrdude.exe: AVR device initialized and ready to accept instructions
avrdude.exe: Device signature = 0xffffff
avrdude.exe: Yikes! Invalid device signature.
avrdude.exe: Expected signature for ATMEGA644P is 1E 96 0A
avrdude.exe: reading input file "G:\Programmierung\Roboter\eigene\Mega644P\main.he x"
avrdude.exe: input file G:\Programmierung\Roboter\eigene\Mega644P\main.hex auto detected as Intel Hex
avrdude.exe: writing flash (310 bytes):
avrdude.exe: 310 bytes of flash written
avrdude.exe: verifying flash memory against G:\Programmierung\Roboter\eigene\Mega644P\main.hex :
avrdude.exe: load data flash data from input file G:\Programmierung\Roboter\eigene\Mega644P\main.hex :
avrdude.exe: input file G:\Programmierung\Roboter\eigene\Mega644P\main.hex auto detected as Intel Hex
avrdude.exe: input file G:\Programmierung\Roboter\eigene\Mega644P\main.hex contains 310 bytes
avrdude.exe: reading on-chip flash data:
avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
0x0c != 0xff
avrdude.exe: verification error; content mismatch

avrdude.exe done. Thank you.

Er behauptet tatsächlich etwas geschrieben zu haben.
avrdude.exe: 310 bytes of flash written

Erst beim Prüfen fällt er auf die Nase
avrdude.exe: verification error, first mismatch at byte 0x0000
0x0c != 0xff

Mit der Zusätzlichen Option -V wird die Überprüfung ausgeschaltet nun sind keine Fehler mehr gemeldet worden.

Kann mir jemand sagen was diese Meldung genauer bedeutet???
avrdude.exe: verification error, first mismatch at byte 0x0000
0x0c != 0xff


Gruß
Ralf

[Willa]

external oscillator heißt überssetzt ins Deutsche eine (kompletter) externer Oszillator. Ein Quarz ist aber keine Oszillator, sondern nur eine Resonator (engl. resonator).

An meinem 644p ist aber ein Oszillator angeschlossen (jedenfalls ist es kein einzelner Quarz, er braucht ne eigene Versorgungsspannung und keine externen Kondensatoren). Ich glaube ich steige trotzdem wieder auf nen mega32 um... Die 4 Mhz mehr und den Speicher des 644 brauche ich anscheinend eh nicht.