www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 1:1 Kopie eines ATMega32


Autor: Manfred Reyzl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will das Programm inkl. EEPROM eines ATMega32 auf einen zweiten
ATMEGA32 kopieren. Ich habe ein STK500 und habe schon alles was mir
dazu eingefallen ist ausprobiert.

Jeweils aus dem alten ATMega32 lesen und dann in den neuen ATMega32
schreiben

1. Flashinhalt lesen -> schreiben
2. EEPROM Inhalt lesen -> schreiben
3. Fuse- und Control-Bits lesen -> schreiben

Leider bringe ich keinen der neuen ATMegas zum Laufen. "Beruhigend"
ist dabei, dass ich es mit mehreren Prozessoren versucht habe und den
selben Effekt bekam. Ich will den Alten ersetzen, da er offensichtlich
einen Defekt an einem Port hat. Leider habe ich die passenden Sourcen
nicht mehr.

Besten Dank für Eure Hilfe.

Autor: Bjoern Buettner (tishima)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind in dem alten Proz die Lock Bits gesetzt, dann kannste dir die 1:1
Kopie abschminken. Nach dem auslesen mal in das Hex bzw. BIN File
schauen, wenn da nur son Müll drinn steht wie 00 01 02 03 04 05 usw.
ist der Prozessor gelockt.

gruß,
Bjoern

Autor: Manfred Reyzl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bjoern,
Lock Bits sind nicht gesetzt. Der alte Prozessor ist ja auch von mir
programmiert worden.
Grüße
Manfred

Autor: inoffizieller WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Fuses wirst du wohl eher manuell einstellen / "kopieren" müssen.
Bei den anderen beiden Speichern solltest du den Umweg über eine Datei
gehen.
Wenn das auch nicht geht, wird deine Zielschaltungen einen an der
Waffel haben...

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also hast du keine Fehlermeldungen die das Lesen betreffen?

Autor: Manfred Reyzl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, Lesen und Schreiben ist jeweils ohne Fehlermeldung.

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dann schau dir mal das ausgelesenen File an ob da überhaupt was
drinsteht was nach Programm auschaut, kannst dir ja die Opcodes mal
anschauen und vergleichen

Autor: pete nerlinger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kompilier doch neu und flash dann den 2. controller. auf die einfachsten
dinge kommen die leute meist werd durch nen kleinen stupser... :)

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
er hat ja den Quellcode seines eigenen Programmes nicht mehr zum
neukompilieren ;-)

zeig mal her dein ausgelesenes .hex File

Autor: Manfred Reyzl (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei das hex file.

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schaut in Ordnung aus, nicht das du was auf dem STK500 falsch gejumpert
hast oder die Taktquelle nicht die richtige ist.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gleich Vorweg: Ich kenn mich da nicht so gut aus. Aber ist das normal,
dass der Disassambler immerwieder zwischendrin einzelne Bytes mit
"Data or unknown opcode" hat?
Oder hast du damals so verstreut Datenbytes im Programm gehabt? Ich
setzt meine Daten normalerweise immer schön am Stück.

Sebastian

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, ich weiss warum. Das sind schon zusammenhängede Daten, aber die
Daten werden vom Disassambler als Opcode interpretiert und für die
meisten der Hexwerte gibts wohl einen passenden Opcode, sodass nur
vereinzelt Daten nicht interpretiert werden.

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wird daran liegen das ein x86 Dissambler nicht alle Befehle(opcodes) des
AVR Assemblers kennt.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt nur noch rein interessehalber, das Problem hat sich ja gelöst: Ich
hab das vom AVR-Studio disassamblen lassen. Der kennt schon alle Befehle
des AVR Assamblers, oder? Du verwirrst mich irgendwie.

@Manfred
Entschuldige bitte die Neugier, aber was hat das Programm eigentlich
gemacht? Schaut aus wie für ein Chemiewerk.

Sebastian

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry das AVR-Studio kann ja auch disassamblen. Dachte du hättest das
mit nem normalen Disassembler gemacht. Habe gerade auch ein Hex-File
durchgejagt und solche Meldungen nicht gefunden, kann es sein das du
den falschen AVR gewählt hast, weil ja bei manchen Typen einige Befehle
fehlen und es AVR-Studio dann vielleicht falsch anzeigt.

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab "Data or unknown opcode" doch noch gefunden dort wo einfach nichts
im Flash steht erscheint das.

Autor: struberg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du solltest beim Ziel Mega32 auch noch darauf achten, ob du die Fuses
für Taktsource (internal, Quarz, externalClock), prescaler (CKSEL0..3),
etc richtig gesetzt hast.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.