Atmega644 reagiert nicht mehr nach Fuse Änderung

tenor

tenor

Mitglied
30. Sep. 2012
169
0
16
44
Sprachen
  1. BascomAVR
Hallo,
ich hatte einige Probleme mit der neu aufgebauten Platine, das LCD hat nur Käse angezeigt, daher dachte ich der Oszillator ist
falsch eingestellt und hab die Einstellung dort angepasst, offensichtlich falsch :(

Ich habe ihn jetzt auf dem Steckboard, allerdings kann ich trotz Quarzoszillator an XTAL1 nicht erkennen.
Einen 16MHz Quarz mit 2 Kondensatoren habe ich auch schon zwischen den XTAL1 und XTAL2 angeschlossen.
Oszillatoren habe ich mehrere versucht, 4 MHz 16MHz und 32MHz.

Hat jemand da eine Idee?
Hoffe nicht das der im eimer ist, war gerade frisch aus der Verpackung....
 
Hallo,

tenor schrieb:
Ich habe ihn jetzt auf dem Steckboard, allerdings kann ich trotz Quarzoszillator an XTAL1 nicht erkennen.
Einen 16MHz Quarz mit 2 Kondensatoren habe ich auch schon zwischen den XTAL1 und XTAL2 angeschlossen.
Oszillatoren habe ich mehrere versucht, 4 MHz 16MHz und 32MHz.
Zum Vergrößern anklicken....
wenn du ihn über den Progger erreichen kannst, dann ist er auch nicht im Eimer. Ob du was auf dem Display erkennen kannst ist eigentlich Sch.. egal. Du mußt ihn ja nur mit dem Progger erreichen.

Also Quarzoszillator dran (4MHz reicht) und dann den AVRISPmk2 auf unter 1MHz einstellen (1MHz ist bereits zu viel). Wenn du ihn dann Signatur abfragen oder auslesen kannst, dann kannst du auch die Fuses wieder richtig einstellen. Der Rest (dein Display) kommt danach wenn er wieder richtig läuft.

Gruß
Dino
 
ich habe den mysmart usb light, da sehe ich erstmal keine Einstellungsmöglichkeiten.
Über bascom kann ich den Programmer auch ansteuern via das stk500 da kann ich auch die Geschwindigkeit auswählen,
aber der sagt mir er erkennt den falschen AVR.

Da habe ich wohl erstmal Pech gehabt... :(
Ich leg den mal zur Seite, vielleicht ergibt sich ja mal was.
 
der Bascom Programmer schreibt nur das er nicht passt:
"Detected Micro does not match the selected Micro ATMEGA644"
Mehr kommt da nicht.
Bin schon die ganze Zeit auf der Suche nach einem alternativen Brenner aber bisher nichts gefunden.
 
Hi,

tenor schrieb:
der Bascom Programmer schreibt nur das er nicht passt:
"Detected Micro does not match the selected Micro ATMEGA644"
Mehr kommt da nicht.
Zum Vergrößern anklicken....
was hast du denn nun genau für einen drin, was steht in deinem Programm genau für nen Typ drin und was schreibt er ganz genau. Mach mal notfalls nen Screenshot.

Ich hab mal ähnliches bei nem Mega8/Mega8A gehabt. Das lag allerdings an Bascom weil sich alphabetisch die Mega8A-Definitionsdatei vor die Mega8-Datei mogelt und er dann nur gegen die testet. Im Programm stand Mega8 und er hat wegen der Reihenfolge und Signatur immer Mega8A angenommen. Hab ich aber streßfrei durch ne kleine Änderung hinbekommen :rolleyes:

tenor schrieb:
Bin schon die ganze Zeit auf der Suche nach einem alternativen Brenner aber bisher nichts gefunden.
Zum Vergrößern anklicken....
Also der AVRISPmk2 ist das Orogonal und da kannst du sicher sein das er auch zukünftige Chips unterstützt. Er kann sogar TPI bei den ganz kleinen Tinys. Ich hab mittlerweile 2 Stück. Einer fest am Schreibtisch und einer der mit dem Laptop mitwandert. Die STK500-Teile sind normalerweise gegenüber dem Original mk2 nen ganze Stück langsamer. Das merkt man dann bei den größeren Teilen am Mega128 ganz extrem (aber auch schon bei nem Mega32).

Gruß
Dino
 
Hallo tenor ,

schau mal nach deiner Spannungsversorgung (atmega644).

Gruß
businski
 
Die Spannung und den Anschluß für den Programmer habe ich natürlich schon mehrfach überprüft, meinen
2. Mega644 habe ich damit auch testweise ausgelesen, da sollte dann kein Problem mehr da sein.

1.jpg2.jpg3.jpg4.jpg

Ein Screenshot vom mysmart usb programmer habe ich nicht gemacht, der schreibt nur das er nichts erkennt.

Das AVR Studio habe ich eben installiert, kenne mich da nicht so mit aus, nach dem einstellen des COM Ports, kann er aber
immerhin den Programmer ansprechen.
Wenn ich die Spannungswerte (siehe Screenshot) verändere und auf write klicke, dann macht er kurz was und dann gehen die Balken wieder runter.
 
Hallo,

also mal Bestandsaufnahme ...

1. im Programm steht Mega644A.
2. Bascom meint das kein Mega644A am Programmer hängt.

3. AVR-Studio kann keine Spannungsmessung des Zielsystems vornehmen (darum 0,0V gemessen).

4. darum (wegen keine Spannung am Zielsystem) kann AVR-Studio nicht in den Programmiermodus gehen.

5. Auf dem Foto sieht man leider nicht ob nun wirklich nen Mega644A drin steckt.
Da die Signatur aber nach meiner Info identisch zum Mega644 (ohne A) ist, sollte das egal sein.

Nun eine Auswertung der Fakten ...

zu 3. => Das wird wohl am Programmer liegen. Die Atmel-Programmer messen die Spannung des Zielsystems um sich daran anzupassen. Er mk2 kann ja immerhin 1,8..5,5V-Controller programmieren. Das kann dein Progger nicht. Darum wirst du wohl da nicht wirklich glücklich werden. Darum ja auch der Fehler beim Punkt 4.

Zu 1. und 2. => Sieh mal im Hauptverzeichnis von Bascom nach. Da findest du eine m644Adef.dat, eine m644def.dat und eine m644Pdef.dat . Zetz mal außer bei der m644Adef.dat ein "Z" vor den Dateinamen (also umbenennen). Damit rutschen die nach ganz hinten in der Sortierung und werden von Bascom nicht mehr als erstes gefunden. Dann versuch es nochmal den Mega644A anzusprechen. Welche Bascom-Version hast du überhaupt am laufen? Wenn es dann nämlich geht, dann liegt es an deiner Bascom-Version. Dann solltest du mal nen Update machen.

Gruß
Dino
 
Danke Dino,
es steht kein A auf dem Atmega, da ich aber 2 identische hier liegen hab, hab ich die def Datei schon entsprechend angepasst,
sprich der 2. wird erkannt.
Ich habe allerdings keinen Unterschied bemerkt zwischen den beiden def Dateien.
Normalerweise schieb ich die hex mit der Software vom MysmartUSB auf die AVR´s, der ist da nicht so zimperlich und ansprechen
konnte er die immer.

Das mit der Spannung erachte ich aber dennoch als merkwürdig...
Ich nutze nicht die Spannung vom Brenner, sondern nutze ein externes Steckernetzteil für die Spannungsversorgung, somit sollte
das doch gehen.

Oder meinst du der Programmer muß die Spannung am System messen bevor er loslegen kann.
Da mein Progger das nicht macht und die mitgelieferte SW trotzdem nicht darauf zugreifen kann, male ich mir mal
schlechte Chancen aus, das der Erwerb des MK2 den AVR retten kann.

Das dumme nur, ich weiß schon gar nicht mehr genau welche Einstellung ich noch verändert hab, neben dem Takt...
 
Hallo,

tenor schrieb:
Danke Dino,
es steht kein A auf dem Atmega, da ich aber 2 identische hier liegen hab, hab ich die def Datei schon entsprechend angepasst,
sprich der 2. wird erkannt.
Ich habe allerdings keinen Unterschied bemerkt zwischen den beiden def Dateien.
Normalerweise schieb ich die hex mit der Software vom MysmartUSB auf die AVR´s, der ist da nicht so zimperlich und ansprechen
konnte er die immer.
Zum Vergrößern anklicken....
Was hast du denn nun genau gemacht damit es auf einmal läuft? Nur den Mega644A gegen nen Mega644 getauscht?
Die Signaturen kannt du auf jeden Fall auslesen. Die sollten theoretisch beim 644 und 644A identisch sein. Der A ist nur ein wenig vom Stromverbrauch verbessert.

tenor schrieb:
Das mit der Spannung erachte ich aber dennoch als merkwürdig...
Ich nutze nicht die Spannung vom Brenner, sondern nutze ein externes Steckernetzteil für die Spannungsversorgung, somit sollte
das doch gehen.
Zum Vergrößern anklicken....
Der my... versorgt die Schaltung aus dem USB-Bus mit Spannung. Er kann aber nicht die Spannung der Schaltung messen.
Der AVRISPmk2 versorgt die Schaltung NICHT. Er benötigt aber die Spannung um sie messen und die Ausgangstreiber darauf einstellen zu können.

tenor schrieb:
Oder meinst du der Programmer muß die Spannung am System messen bevor er loslegen kann.
Da mein Progger das nicht macht und die mitgelieferte SW trotzdem nicht darauf zugreifen kann, male ich mir mal
schlechte Chancen aus, das der Erwerb des MK2 den AVR retten kann.
Zum Vergrößern anklicken....
Das liegt nicht am Progger ob du den Mega nun ansprechen kannst oder nicht. Das liegt an der Anschaltung an deinen Atmel und an der Programmiersoftware.

tenor schrieb:
Das dumme nur, ich weiß schon gar nicht mehr genau welche Einstellung ich noch verändert hab, neben dem Takt...
Zum Vergrößern anklicken....
Schreib dir das doch in deinen Programmkopf als Bemerkung rein was du für das Programm benötigst.

Code: 
' ========== ATmega32-FUSES ==========
'
' * SUT1 und SUT0 (Zustand=11): Start-up Time 65ms nach Reset,
'   Einstellung für Quarzoszillator und langsam ansteigende
'   Betriebsspannung (Tabelle 5 des Datenblattes)
' * CKSEL3-CKSEL0 (Zustand=1111): Quarzoszillator im Bereich 3-8MHz
'   (Tabelle 4 des Datenblattes)
' * CKOPT (Zustand=1): schneller Quarzoszillator (Tabelle 4 des Datenblattes)
' * BODEN (Zustand=0): Brown-out einschalten
' * BODLEVEL (Zustand=1): Brown-out Schwelle auf 2,7V setzen
'
'  Unter Beachtung der invertierten Logik der Fuse-Bits sollte man
'  also die Fuses so setzen wie im folgenden Bild:
'
' ( )7 ( )6 [ ]BootLock12 [ ]BootLock11 [ ]BootLock02 [ ]BootLock01 [ ]Lock2 [ ]Lock1
'
' [ ]OCDEN [ ]JTAGEN (X)SPIEN [ ]CKOPT  [ ]EESAVE [X]BOOTSZ1 [X]BOOTSZ0 [ ]BOOTRST
'
' [ ]BODLEVEL [X]BODEN [ ]SUT1 [ ]SUT0 [ ]CKSEL3 [ ]CKSEL2 [ ]CKSEL1 [ ]CKSEL0
'  ______________________
' |                      |
' | [X] Bit=0  [ ] Bit=1 | ( ) -> Nicht anwaehlbar  [ ] -> Anwaehlbar
' | progr.     unprogr.  |
' |______________________|

Gruß
Dino
 
Ich hab da nichts geändert nur den anderen identischen AVR verwendet, somit weiß ich das die Einstellungen passen.
Interessanterweise muß ich in Bascom die A Variante nehemen ($regfile = "m644adef.dat" )
obwohl das A auf dem Chip nicht drauf steht.
Der andere Progger ignoriert das halt und schreibt alles. Nur diesen AVR erkennt er nicht mehr.
Und bei dieser Software kann ich den Bustakt nicht einstellen...

Das mit den Fuses in den Programmkopf ist sicher ne gute Sache, werde ich beim nächsten mal dran denken...
Denn die SW die vorher voll funktioniert hat, geht in dem neuen AVR nicht mehr... PWM wird nicht mehr erzeugt...
Aber dafür mache ich einen neuen Thread auf, aber erst wenn ich nicht mehr weiter weiß ;)
 
Hallo,

ich hab jetzt mal beim AVR-Studio5 im Devices-Ordner in den XMLs gestöbert ...

ATmega644.xml
<property-group name="SIGNATURES">
<property name="JTAGID" value="0x0960903f"/>
<property name="SIGNATURE0" value="0x1e"/>
<property name="SIGNATURE1" value="0x96"/>
<property name="SIGNATURE2" value="0x09"/>
</property-group>

ATmega644A.xml
<property-group name="SIGNATURES">
<property name="JTAGID" value="0x0960A03f"/>
<property name="SIGNATURE0" value="0x1e"/>
<property name="SIGNATURE1" value="0x96"/>
<property name="SIGNATURE2" value="0x09"/>
</property-group>

ATmega644P.xml
<property-group name="SIGNATURES">
<property name="JTAGID" value="0x0960A03f"/>
<property name="SIGNATURE0" value="0x1e"/>
<property name="SIGNATURE1" value="0x96"/>
<property name="SIGNATURE2" value="0x0a"/>
</property-group>

Also der Mega644 und der Mega644A haben wie vermutet die selbe Signatur.
Wenn es also mit nem 644 klappt und mit nem 644A nicht oder andersrum, dann wird es irgendwie an der Software liegen und nicht am Progger oder an der Hardware. Dann fehlt in der Prog-Software die Info das es den Mega644A gibt und er dieselbe Signatur hat.

Also entweder Progsoftware updaten oder einfach angeben das es sich um nen normalen Mega644 ohne A handelt.

Gruß
Dino
 
Das Thema hat zwar jetzt nichts mehr mit dem "toten" AVR zu tun, aber Bascom spinnt da etwas..
Ich habe bisher immer mit der "$regfile = "m644def.dat" gearbeitet. Und nie ein Problem damit gehabt.
Eben wollte ich den Timer 2 konfigurieren und es passiert nichts mehr.
Nachdem ich es dann ausgeschrieben hab:
"Config Timer2 = Pwm , Compare A Pwm = Clear Down , Compare B Pwm = Clear Down , Prescale = 128 'Timer 2 = PWM für 1-10V Dimmer"
Kam die Meldung das Config Timer2 nicht richtig wäre...
Als ich die def Datei auf m644adef.dat geändert hab, hat es wieder funktioniert..
Also irgendwas passt hier bei mir überhaupt nicht.

Wie gesagt das ist mit dem 2. AVR, der erste gibt kein Mux von sich, ich komm da nicht so weit das ich was einspielen könnte.
 
Hi,

tenor schrieb:
Kam die Meldung das Config Timer2 nicht richtig wäre...
Als ich die def Datei auf m644adef.dat geändert hab, hat es wieder funktioniert..
Also irgendwas passt hier bei mir überhaupt nicht.
Zum Vergrößern anklicken....

welche Version von Bascom hast du denn nun genau? Ich hab mal sowas ähnliches gehabt was aber bei ner neueren Version abgestellt sein soll.

Gruß
Dino
 
Ich teste gerade mit der aktuellen Demo Version, die hat 2.0.7.5.
Sollte daher nicht zu alt sein.

Sind halt immer so Sachen die ich nicht verstehe.. Dachte erst ich hätte es so halbwegs raus mit meinem Programm und jetzt
will ich das nur in einen neuen Controller unterbringen und schon gibts Probleme mit den Grundlagen...

Naja, zumindest funktioniert es wenn ich da die andere def Datei nehme...
 
Hallo,

tenor schrieb:
Sind halt immer so Sachen die ich nicht verstehe.. Dachte erst ich hätte es so halbwegs raus mit meinem Programm und jetzt
will ich das nur in einen neuen Controller unterbringen und schon gibts Probleme mit den Grundlagen...

Naja, zumindest funktioniert es wenn ich da die andere def Datei nehme...
Zum Vergrößern anklicken....

das ist alles eine Frage wie Bascom die Signaturen behandelt. Bei mir war das Problem glaube ich in Version 2.0.7.3 oder 2.0.7.4 .

Wenn du proggen willst, dann steht ja in deinem Programm die Mega644A.def mit entsprechender Signatur für den Mega644A (identisch mit dem Mega644).
Bascom fragt dann die Signatur des Controllers ab und sucht in seiner Liste nach dieser Signatur. Je nachdem wie nun die Liste sortiert ist kommt Bascom nun zum ersten Eintrag bei dem die Signatur paßt. Der Eintrag wird nun angesehen und erkannt das da zB "nur" Mega644 steht und nicht Mega644A. Da diese Angabe nicht zu deiner Angabe im Quellcode paßt wird also gemotzt. Egal ob die Signaturen nun identisch sind oder nicht. MCS wollte das eigentlich beheben. Ob die das nun gemacht haben oder nicht weiß ich nicht. Müßte man mal ausprobieren.

Gruß
Dino
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
    • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
    •  Registriere dich

User Menu

Anmelden

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)

Oben Unten
Zurück