Hallo! Wie im Betreff schon erwähnt, habe ich ein Problem mit dem Self-Programming beim Umstieg von ATtiny84 auf ATmega168. Auf dem ATtiny84 habe ich ein C-Programm, welches sich im Flash einen Speicherbereich an fester Hardware-Adresse definiert hat, in dem es Daten speichern und daraus lesen kann. Dazu konnte ich ja die Self-Programming-Funktion nutzen. Nun muss ich auf den ATmega168 umsteigen und dort verhält es sich mit dem Self-Programming so, dass nur Code welcher in der Boot Flash Section steht, Schreibzugriff auf das Flash bekommt. Also habe ich mir per Linker-Definition einen Bereich in der Boot Section definiert und den Code-Teil meines Programms, der Schreibzugriff braucht, dorthin verschoben. Das Problem ist, dass bei der Ausführung des Programms nun an der Stelle wo in den 'ausgelagerten' Code gesprungen wird, irgend etwas mir bisher unbekanntes passiert. Als Resultat zeigt sich es jedenfalls so, dass nach dem Ausführen des Codes im Boot Sector und dem Rücksprung ins reguläre Programm mein CSTACK und RSTACK überlaufen und Variablen des Programms falsche Werte haben. Das Programm verhält sich absolut fehlerhaft. Hat jemand schonmal etwas Ähnliches gehabt, oder weiss wo mein Fehler liegen könnte? Gruß Florian
"Mein Programm funktioniert nicht. Hat das schon mal jemand gehabt"? Nein, du bist der erste. Allerdings ist bei so etwas Zeile 42 immer verdächtig, vor allem im C- und RSTACK... Oliver
Oliver S. schrieb: > "Mein Programm funktioniert nicht. Hat das schon mal jemand gehabt"? > > Nein, du bist der erste. Allerdings ist bei so etwas Zeile 42 immer > verdächtig, vor allem im C- und RSTACK... > > Oliver Ah, ein Komiker - wirklich nett. Ich machs kurz: Danke für nichts! In Zukunft bitte ernst gemeinte Antworten
Gast
#3564510
Wo ist der Source Code zum einsehen?
Stefan us schrieb: > Wo ist der Source Code zum einsehen? Hier meine Flash-Schreibe-Routine
Florian K. schrieb: > Ah, ein Komiker Na ja, du hast schließlich angefangen. Es gibt zwar keine dumme Fragen, aber du warst nah drann. Solche Fragen ohne Code sind sinnlos. Gleich danach kommt allerdings, zur Frage den falschen Code zu zeigen. Ich wette, daß das der Code vom Tiny ist, und ich würde mich wundern, wenn der für einen Mega168 fehlerfrei compiliert. CTPB kennt der Mega168 nicht. An der Stelle würde ich dann mal ansetzen. Oliver
Oliver S. schrieb: > Ich wette, daß das der Code vom Tiny ist, und ich würde mich wundern, > wenn der für einen Mega168 fehlerfrei compiliert. CTPB kennt der Mega168 > nicht. An der Stelle würde ich dann mal ansetzen. Der Code ist vom tiny, aber ich habe auch schon per define CTPB in RWWSRE geändert. Als Entwicklungsungebung nutze ich IAR embedded workbench und die inkludiert auch alles Nötige, um die Abwärtskompatibilität zu gewährleisten (ua wird SPMEN zu SELFPRGEN definiert). Der Code lässt sich somit sehr wohl fehlerfrei kompilieren.
- Interrupts komplett sperren - alles ins @"BOOT_SEGMENT" Was ist dieses const PartitionTable_t* Partition? Wozu brauchst Du es?
Florian K. schrieb: > Der Code lässt sich somit sehr wohl fehlerfrei kompilieren. Na ja, prima. Der gezeigte Code aber nicht. Worauf ich allerdings hinaus wollte, ist, das das Bit von Atmel nicht umbenannnt wurde, sondern daß das Bit in dem Register beim Mega was ganz anderes macht als beim Tiny, und daß daher auch im Programm reines umbenennen eventuell nicht ausreicht. RTFM. Das die unterschiedlich großen pagesizes in der Partitionstabelle berücksichtig wurde, setzte ich jetzt einfach mal voraus. Oliver
Erfolg! Für alle, die es interessiert: Ich habe den Fehler gefunden. Es muss der Read-While-Write-Bereich des Flashs nach einem PAGEWRITE-Befehl wieder reaktiviert werden. Die Änderungen sind im Code in Zeile 26. Das nachfolgend Auskommentierte ist somit unnötig. Gruß Florian
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.