ATMEGA 644P 20PU

Hallo,
habe mir einen paar ATMega 644P zugelegt.
Ich wollte ein kleines Programm aufspielen und bekommen keine Bestätigung über den ISP Adapter.
Versucht habe ich es verschiedenen Programmen.
BASCOM, AVRDrude.


Angeschlossen habe ich den ATMega wie einen ATMEGA 32 oder 16.

Bei keinem der gelieferten ATMega 644 bekomme ich Info zurück, über ISP.

Kann mir hier jemand einen Tip geben?

Der ATMEGA 64 hat zwar eine Besonderheit, siehe hier
http://www.mikrocontroller.net/artic..._.2F_ATmega128

jedoch habe ich die Pin Beschreibung geprüft und keinen Unterschied zum ATMEGA 32 / 16 festgestellt

Gruß
Ralf

Der Mega644P ist noch ziehmlich neu. Ist den da schon eine Unterstützung vorgesehen ? Kann den die Chip ID ausgelesen werden? Wenn man nur 0xFFFFFF oder 0x000000 als ID kriegt ist es wohl eher ein HW Problem, sonst eher ein Software Problem.

Hi Besserwessi,

der AVRDrude meldet
avrdude.exe: AVR device not responding
avrdude.exe: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

BASCOM meldet
Could not identify chip with ID:FFFFFF

Wenn ich im AVRDrude die Option -F mit gebe gibt es mehr Infos
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 ATMEGA644 is 1E 96 09
avrdude.exe: reading efuse memory:
avrdude.exe: writing output file "d:\TEMP\efuse35082.hex"
avrdude.exe: reading hfuse memory:
avrdude.exe: writing output file "d:\TEMP\hfuse35081.hex"
avrdude.exe: reading lfuse memory:
avrdude.exe: writing output file "d:\TEMP\lfuse35080.hex"

Also die Signatur kann scheinbar gelesen werden.
Keine Ahnung was das bedeutet

Das keine Signatur gelesen werden kann, heißt das die Komumication gar nicht geht. Das Problem sollte damit weitgehend unabhängig vom Controller sein, also eher was an der Hardware oder eine Problem mit Windows und dem LPT-Zugriff.

Hallo,

in der aktuellen Bascom ist der 644P schon enthalten, wenn man die 1.11.9.2 schon länger hat muss man ein update holen, dann bekommt man die config-Datei für den 644P dazu.
Wenn man die Demo hat, kann man sich mit dieser behelfen:
https://www.roboternetz.de/phpBB2/ze...ighlight=*644p

Hallo linux_80,
meine Bascom Version (Demo) kennt den 644 bereits, kann manuell ausgewählt werden, bekomme dennoch die Meldung "Could not identify chip with ID:FFFFFF". Werde dennoch mal die BASCOM Version updaten (Version 1.1.8.7)
Hast Du denn den ISP so wie bei einem ATMEga32 angeschlossen?
So habe ich es gemacht.


@Besserwessi:
Daran habe ich bereits auch gedacht, habe an die gleiche Stelle einen ATMega 32 gesetzt und es funktioniert.
Wenn es ein Windows Problem währe sollte hier doch das gleiche Problem auftreten, oder?

Gruß

Hallo raf,

wirklich ein sehr merkwürdiges Problem. Den Atmega64 sollte man nicht mit dem 644 verwechseln. Der Atmega64 hat ebenso wie der Atmega128 einige Fallstricke, die aber beim Atmega644 nicht vorhanden sind. Dieser ist definitiv Pinkompatibel mit dem Atmega16/32 und sollte ganz schlicht und einfach funktionieren.
Wenn er es doch nicht tut, kann ich mir nur vorstellen, das er etwas empfindlicher ist, was seine Stromversorgung angeht. Vielleicht an den entsprechenden Pins noch 100nF-Kondensatoren hängen.

Etwas Schlaueres fällt mir dazu leider auch nicht ein.

Ist der Atmega denn bis auf die ISP-Hardware unbeschaltet, oder sind schon irgendwelche Lasten an den Ports oder ähnliches?

Gruß MeckPommER

Hallo MeckPommER
die Pin Kompatibilität habe ich aus der Doku entnehmen können, von den Problematiken ATMega 64/128 habe ich gelesen und mich deswegen für die 644 entschieden.

Habe den Mega 644 den wie folgt beschaltet
Pin 6,7,8,9 ISP,
Pin 9 mit 100K an +5V
Pin 10 an +5 V
Pin 11 an GND
Zwischen Pin 10 und 11 100n Kondensator (Keramik)
Pin 30 und 32 an +5V
Pin 31 an GND
Zwischen Pin 30 und 31 100n Kondensator (Keramik)
sonst keine weitere Belegung.

Als Netzteil habe ich eine Spannungsregler 7805 (Selbstbau)

Das war es.

Gruß
Raf

Ob es wohl möglich wäre, das die µC auf Quarzbeschaltung gefused wurden? Halte ich für arg unwahrscheinlich, aber unmöglich ist ja nichts ;-)
Wäre ja eine nette Überraschung, wenn die Fuses im Auslieferungszustand "ungünstig" gesetzt sind. Falls du zwei 22pF-Kondensatoren parat hast und Quarze zum Testen - so 1MHz vielleicht - schaden kann es nicht, das mal auszuprobieren.

Zu deinem Aufbau:

Von Reset (Pin 9) nach +5V würde ich einen kleineren Widerstand als 100K nehmen, z.B. 15k.

Beim Erstaufbau würde ich +5V von AREF entfernen und von AREF mit einem 100nF-Kondensator nach GND gehen.

Was dein Netzteil angeht, kann ich natürlich nicht viel sagen ... aber ein dicker Elko > 100µF kann nicht schaden.

Da dein Aufbau mit den kleinen Atmegas funktioniert, "müßte" es an den Fuses liegen, obwohl auch das recht unwahrscheinlich ist. Aber wie schon Sherlock Holmes sagte: wenn das Wahrscheinliche ausgeschlossen ist, dann ist die Lösung im Unwahrscheinlichen zu suchen.

Gruß MeckPommER

@raf
Du schreibst aber Du hast einen Mega644P, das ist ein anderer als ein 644 ohne P, deswegen hab ich die Datei gebaut !

Dein Problem ist aber dennoch erstmal das es garnicht soweit kommt mit der Flasherei.

Pinkompatibel sind Mega32, Mega644 und Mega644P.

@linux_80
ich habe mir Deine Datei dennoch runtergeladen und Installiert, schadet nichts.

OK wo ist denn der genaue unterschied zwischen den beiden uC`s?

@MeckPommER
Sorry meinte nicht 100K Widerstand sondern 10K.
Werde Deinen Vorschlag ausprobieren, habe jedoch nur einen 7,3728Mhz und 16Mhz Quarz, wird wohl keine große Geige spielen, oder?

Gruß
Ralf

Je nach Einstellung der Fuses könnte es sein, das ein 16MHz Quarz nicht sauber läuft. Viel Glück und Erfolg beim Ausprobieren!

Hmmmm, ich stehe grad vor dem selbem Problem, wenn ich meinen ATMEGA32 gegen einen 644 auswechsle, dann erkennt BASCOM (1.11.8.7) den Chip nicht mehr. Egal ob ein 20MHZ oder ein 16MHZ Oszillator dran ist... Hat jemand mal eine Lösung gefunden?

In dem thread oben war das wohle her ein hardware Problem. Die nicht auszulesende ID sollte nicht durch ein einfaches Software update für den neuen Chip zu beseitigen sein.


@willa: Wenn die Schaltung vorher mit dem Mega32 funktioniert hat, sollte man die ID auslesen können. geht das denn ?
Bei Bascom muß man schon für das compilieren eine Mega644 oder wenigstens ersatzweise Mega324 einstellen, damit die Register stimmen. Wenn das geht sollte aber auch der Programmieren keine Probleme mahr machen. Im neuzustand läuft ohnehin alles über den internen Oszillator, da ist der Quarz egal.

Hi Besserwessi,
also eine "unknown ID" wird ausgelesen, im Code sowie im Programmmenü steht m644def.dat. Sollte es also einfach an der Bascom-Version liegen? Das wundert mich halt ein bisschen, weil die definitionen für den 644 bei 11.8.7 dabei sind, also dann doch auch funktionieren sollten...?
Dann werde ich mal die neueste Version austesten.

hier hatte jemand das selbe Problem: habs nur überflogen, aber evtl. hilft es ja...? http://www.forum64.de/wbb3/index.php...threadID=22463
Gerald

Was ist dass denn für eine ID die Ausgelesen wird ?
Wie schon oben gesagt ist 000000 oder FF FF FF sehr wahrscheinlich eine hardware- Problem, alle anderen eher eine Softwareproblem.

@willa:
Weiter oben steht, dass Bascom den mega644 erst nach 1.11.9.2 kennt. Einfach mal upgraden...

Nicht verwechseln 644 mit und ohne P !
Der 644er ohne P geht schon lönger, den mit P erst mit update zur .9.2.

Naja, hier gehts ja um den P...

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.

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.

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

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

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

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?

@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

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.

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

Zitat:

---

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.

@RAF
Du hast -F angegeben. Das bedeutet, dass er jegliche Fehler ignoriert. D.h., wenn er sagt, er schreibt, dann versucht ers zwar, aber wenn der Chip die Daten nicht annimmt (und bestätigt) bricht avr-dude halt nicht ab.

Geschrieben wurde bei Dir nichts. Die Fuses sind bestimmt auch alle low.

Solange die Verbindung nicht gescheit ist, wird das nicht funktionieren.

@thewulf00,
die Frage ist nur wie komme ich an den uc?

Wenn ich in das gleiche Board nun einen AT32 setzte wird der problemlos geflasht.

Da die FUSES ohne die Option -F nicht gelesen werden, mit der Option -F können die zwar gelesen werden, ich kann jedoch nicht mit Sicherheit sagen ob die angezeigten FUSES richtig sind.
Nachdem Auslesen werden keine gesetzten FUSES angezeigt, währe also alles LOW.
Die Default Einstellungen habe ich versucht zurückzuschreiben. Klappt nicht Meinewrmeinung nach hauptsächlich wegen SPIEN der steht auch auf LOW.
Folgende stehen auch noch auf LOW
BOOTSZ1
BOOTSZ0
CKDIV8
SUTO
CKSEL3
CKSEL2
CKSEL0

Reicht es das der SPIEN mit einem externe Quarz zu versorgen? Hatte ich schon mal versucht jedoch kein Erfolg. Zumal in meinem Board bereits ein Quarz hinterlegt ist.

Nutze das Evalutionsboard Funk AVR von Pollin.

Gruß
Ralf

Du kannst diese Möglichkeiten durchprobieren: (Wenn keine davon Erfolg bringt, kann ich Dir nicht mehr helfen)
1. Quarz zwischen XTAL1 & XTAL2 (22pF-Kondensatoren nicht vergessen).
2. Quarz-Oszillator an XTAL1.
3. Beschaltung komplett kontrollieren, Datenblatt zurate ziehen!
4. Schaltung mit Hand aufbauen (mit Sockel, hinterher IC einstecken; oder auf Steckbrett).
5. Einen anderen Mega644P nehmen und 1-4 nochmal durchgehen.