hallo! ich benutze den GNU compiler und das AVR studio 4.06 für eine Entwicklung mt dem ATmega162. Beim Start des Studios wird neben dem Programmspeicher dummerweise auch jedesmal der Daten-EEPROM mit FF gefüllt und damit nichtflüchtige Daten überschrieben. Ich vermute, das liegt an dem Coff-File, der beim Start des studio geladen wird. Dieses Coff-File scheint u.a. den EEPROM-Inhalt (mit lauter FF's) zu enthalten. Weiss jemand, wie ich - entweder das eeprom-Überschreiben im Studio abschalten kann - oder den EEPROM-Inhalt in das Coff-File hineinbekomme? - oder den EEPROM-Inhalt über irgenndwelche Hexfiles wieder restaurieren kann?? Gruß Martin
Erstens solltest Du wohl besser das letzte Beta von AS 4.07 benutzen, selbst das enthält noch genügend Bugs... Zweitens enthält das COFF-File keine EEPROM-Inhalte. Meines Wissens werden dafür bestenfalls separate Dateien benutzt, aber Du solltest wohl besser in einem allgemeinen Forum fragen, da das eine reine AVR-Studio Frage ist.
Gibt's bei den Fuses keine, die das Löschen des EEPROMS bei Chip Erase verhindert? Wie programmierst Du? /Berndt
danke Jörg + Berndt Wenn ich die Fuse "Preserve EEPROM memory through the Chip erase cycle [EESAVE=0]" setze, dann ist trotzdem anschliessend der EEPROM gelöscht, sprich 0xFF. Die einzige Auswirkung ist, dass die Meldung "lade EEPROM memory" beim Laden des Coff-Files nicht mehr kommt. Möglicherweise ist das wirklich ein Bug im Studio 4.06. Es soll in Kürze (geplant war heute) das 4.08 er Studio herauskommen. Programmieren tue ich über den JTAGICE aus dem Studio heraus, dabei tritt eben genau der Fall ein. Wenn ich mit dem AVRISP programmiere, dann kann ich schön alles angeben, was gelöscht bzw. unverändert gelassen wird. Gruß Martin
»in Kürze« ist gut. :-) Ich kenne von einer Atmel-internen Quelle den Juni 2003 als geplanten Termin für ein non-beta AVR Studio 4.07, jetzt haben wir Oktober... Zumindest wird die nächste Version endlich die Bugfixes im COFF Parser haben, die die Initialisierung des .data-Inhalts im Zusammenspiel mit AVR-GCC + avr-objcopy -O coff-ext-avr betreffen. Aber wie geschrieben: einen EEPROM-Inhalt gibt es nicht in den COFF-Files (der wird beim avr-objcopy nicht mitkopiert), und selbst wenn es ihn gäbe, würde AVR Studio ihn ignorieren. Die lesen nur .text ein (mit dem Bugfix dann auch .data, falls die Datenquelle sich als avr-gcc ausweist) sowie die Debug-Symbole. EEPROM-Inhalte müssen woanders her kommen, RTFDoc -- sorry, ich habe kein Windows, ich nehme kein AVR Studio. Aber wenn Du eh' einen JTAG ICE Dein eigen nennst, kannst Du ja auf AVR Studio auch gleich verzichten. Nimm den GDB (z. B. zusammen mit Insight, wenn Du was grafisches drumrum gewickelt haben willst) und AVaRICE. Nie wieder COFF-Probleme!, und einen ordentlichen Debugger gleich noch dazu. :-)
hmm ich habe soeben den avrinsight mal gestartet, sieht aus wie ein Debugger. was für ein ladefile braucht der denn? Gruß Martin
@Martin Was willt Du mit AVRStudio machen ? Ein Programm debuggen (Simulator) oder ein Hex-File auf ein Target mittels STK500 laden ? Will man mit AVRStudio ein Programm debuggen, das Initialisierungs-Daten aus dem EEPROM lädt, das zur Compile-Zeit initialisiert wurde, (.section .eeprom), muss man nach dem Laden des Coff-Files in AVRStudio dieses EEPROM hex file separat laden mittels AVRStudio Menu Debug->Up/Downlaod Memories... Beim Reload eines Coff-Files ohne AVRStudio neu zu starten bleiben aber die EEPROM Daten erhalten. Diese auch Beispiel "test_eeprom" auf meiner Homepage: http://www.mysunrise.ch/users/pfleury/avr-software.html
@Peter: schrob er doch (ein wenig): via JTAG ICE Programm laden und vermutlich auch debuggen, also eher nicht simulieren. @Martin: Der GDB kann das ganz normale ELF File nehmen, so, wie es aus der Kette rauskommt. Der braucht aber ein Backend, gegen das er arbeiten kann, da der Hostprozessor ja kein AVR ist. Die beiden möglichen Backends sind simulavr und AVaRICE. simulavr ist ein eifacher Simulator für die AVR-Prozessoren, während AVaRICE das Bindeglied zum JTAG ICE ist, so daß der GDB dann den physischen AVR-Prozessor für die Abarbeitung benutzen kann. Das Grundprinzip ist: 1.) avarice starten => der verbindet sich mit dem JTAG ICE und arbeitet danach als TCP-Server auf der lokalen Maschine (standardmäßig auf Port 4242) 2.) GDB starten (bzw. GDB via Insight) 3.) GDB mit dem avarice verbinden; "target remote :4242", keine Ahnung, wie man das im Insight angibt 4.) Falls bei avarice nicht bereits die ELF-Datei angegeben worden ist (dann würde der den AVR bereits programmieren wollen), dann jetzt mit "load" das Abbild aus dem GDB zum JTAG ICE schieben. 5.) Debuggen
@Peter: ich möchte lediglich, dass beim Laden des Programmes bzw. beim Start des Studio das EEPROM so bleibt wie es ist. Der ATmega schreibt zur Laufzeit daten dort ein, und die sollen einfach bei der nächsten Sitzung noch da sein.... @Joerg tja, wenn ich avarice starte (aus einem DOS Fenster heraus), dann kommt die Meldung: C:\Programme\Atmel\WinAVR\bin>avarice AVaRICE version 2.0.20030825cvs, Sep 12 2003 12:56:48 Failed to open /dev/avrjtag: No such file or directory hab ich hier was icht korrekt installiert??? Gruß Martin
Nein, aber ein bißchen RTFDoc darfst Du schon auch selbst tun, also zumindest dessen Kommandozeilenparameter solltest Du Dir mal antun. Ein Forum sollte nicht als Manual mißbraucht werden, zumindest nicht, solange Manuals da sind. Falls das Manual nicht dabei sein sollte, dann bekommst Du zumindest eine Kurzzusammenfassung mit: avarice --help
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.