Hallo Forum, Mein C Programm auf Atmega8 (+8MHz) verhält sich völlig anders je nachdem ob ich es mit Ponyprog aufspiele, oder den Bootloader (von Peter Dannegger) verwende. (Pollin Board und eigengebautes Board ergibt dasselbe Verhalten) Mein Programm lässt sich fehlerfrei kompilieren, die *.hex Datei kann ich mit Ponyprog auf meinen AVR aufspielen und das Programm läuft stundenlang ohne Probleme. Jedes mal wenn ich Reset drücke, startet es brav mit ein paar Ausgabezeilen über den UART und einer leuchtenden LED. Das funktioniert zuverlässig. Im Gegensatz dazu: Über Bootloader geladen lässt sich das Programm nur 2-3 Mal ausführen. Soll heißen, wenn ich Reset drücke, gibt der Mikrocontroller wie er soll einige Textzeilen über den UART aus und eine LED leuchtet. Das funktioniert dann 2 oder 3 Mal – die nächsten Male wird dann nichts mehr ausgegeben/ keine Led leuchtet. Noch seltsamer ist, dass ich mir dabei auch irgendwie den Bootloader zerschieße. Mein Hauptprogramm kann ich also erst wieder aufspielen, nachdem ich auch den Bootloader frisch draufgepackt habe. Wenn ich den Speicher des AVR nach einem solchen Crash mit Ponyprog auslese, kann ich allerdings keinerlei Beschädigung an dem Programm- oder Bootloaderteil ausmachen – zwischen beiden Teilen ist noch nen dicker Abstand frei. Irgendwie geht’s für mich an dieser Stelle seit letzter Woche nicht mehr weiter und ich wär auf eure Hilfe angewiesen. vielen Dank Mickey
Nabend. Ich hatte mal genau das gleiche Problem. Darauf hin habe ich den Bootloader ein wenig umgeschrieben, sodass er vorm starten des Programms einen WD-Reset durchführt (war zu faul alles zu überprüfen). Dies hat bedingt geholfen. Nun arbeite ich wieder ohne den Bootloader.
Danke dir, arbeite mit diesem Bootloader erfolgreich in ner Menge anderer Projekte und will ihn nicht mehr missen. In diesem Fall zerstör ich mir da aber immer was. Der Hex Code vom Bootloader auf dem AVR bleibt unverändert - ob ich mir da eine Einsprungstelle oder so kaputtmache - keine Ahnung. Vielleicht fällt noch mal jemandem was ein Mickey
Michael Jaeger schrieb: > Noch seltsamer ist, dass ich mir dabei auch irgendwie den Bootloader > zerschieße. Michael Jaeger schrieb: > Der Hex Code vom > Bootloader auf dem AVR bleibt unverändert Dann ist er doch nicht zerschossen. Da ist irgendwas anderes faul. Vielleicht kommt die VCC zu langsam, ist die Resetzeit zu kurz, schwingt der Quarz schwer an, schwankt die VCC, ... Les mal den MC nach dem Programmieren über SPI aus (Applikation + Bootloader) und wenn er spinnt, mach Verify.
Danke dir, meine Schaltung wird über Netzteil + Spannungsregler versorgt. Bei anderen Programmen hab ich keinerlei Schwierigkeiten beim Laden. So nun hab ich meinen Fehler weiter eingrenzen können, bin allerdings immer noch ratlos. Ich bin folgendermaßen vorgegangen: - Bootloader aufgespielt über ISP (verify ok) - Hab einige meiner anderen bewährten Programme mittels Bootloader aufgespielt – funktionieren alle tadellos. - Meine main.hex (die mich z.Zt. wie oben beschrieben so ärgert) mit Hilfe des Bootloaders aufgespielt (Aufspielen funktioniert) fboot /C1 /Pmain.hex COM 1 at 115200 Baud: Connected Bootloader V2.1 Target: 1E9307 ATmega8 Buffer: 960 Byte Size available: 7680 Byte Program main.hex: 00000 - 016B9 successful CRC: o.k. - nun habe ich versucht den letzten Schritt noch mal zu wiederholen – also die „böse“ main.hex noch mal per Bootloader zu laden. Aber das geht jetzt schon nicht mehr; ich bekomme nur noch: fboot /C1 /Pmain.hex COM 1 at 115200 Baud: - - daraufhin hab ich per ISP den gesamten Speicherbereich nochmal ausgelesen. Der Bootloader schaut immer noch unverändert aus – verify funktioniert und es ist immer noch ein dicker Abstand zwischen Quellcode und Bootloaderbereich. Hab ich da irgendeine Platzbeschränkung noch nicht richtig verstanden ? Beim fehlerfreien Kompilieren meines Quellcodes wird mir folgende Codegröße angezeigt: Size after: main.elf : section size addr .text 5336 0 .data 482 8388704 .bss 75 8389186 .debug_aranges 128 0 .debug_pubnames 689 0 .debug_info 2985 0 .debug_abbrev 1314 0 .debug_line 3979 0 .debug_frame 528 0 .debug_str 1127 0 .debug_loc 1081 0 .debug_ranges 120 0 Total 17844 vielleicht noch eine Idee? Mickey
Michael Jaeger schrieb: > vielleicht noch eine Idee? Programm-Hex in AVR-Studio 4 öffnen und ab Word-Adresse 0xF00 nachsehen, ob der Bootlader-Bereich leer ist.
Danke euch, hab nun zum wiederholten Male einen Textvergleich angestellt. Verglichen hab ich dabei Hex Files die ich per ISP aus meinem Atmega ausgelesen habe. Hex Datei 1 zeigt den frisch aufgespielten Bootloader. Datei 2 Bootloader + per Bootloader geladene main.hex, wobei ein erneutes Verwenden des Bootloaders, wie oben beschrieben hier schon nicht mehr möglich ist. Der Anfang der Dateien unterscheidet sich natürlich, aber der Textvergleich zeigt einen identischen Bereich ab 1E00 (siehe jpg). Das ist für mich das Zeichen, dass mit dem Bootloader alles in Ordnung sein sollte. Oder gibt's noch eine andere Stelle, die ich kontrollieren muss? Hab in meiner Verzweiflung auch noch mal meine FuseBits angehängt - oder mach ich da was falsch? gruß Mickey
Sofern es nicht um extrem sparsamen Batteriebetrieb geht, sollte das BOR immer an sein.
Zeig doch mal deine bootlader.hex Datei. Wo kommt der Code bei 0x1b90 her? Und zeig auch deine Main.hex Datei. Nicht, dass sich da Bereiche überlappen...
Scheint das uart empfaengt nichts. Allenfalls wurde das Uart unvollstaendig initialisiert.
Danke euch, So mein Problem hab ich gerade eingrenzen und beseitigen können. So ganz verstehen tu ich’s allerdings noch nicht. Bei Programmstart (der ja nach dem Bootloaderdurchlauf bzw. bei Reset startet) geb ich ein Menü über den UART aus
1 | void menueStrukturAusgeben(void) |
2 | {
|
3 | PORTD |= (1 << D5); |
4 | |
5 | uart_putc ('\r'); |
6 | uart_puts("Bitte einen Menüpunkt auswählen:\r"); |
7 | uart_putc ('\r'); |
8 | uart_puts("A EEProm Inhalt ausgeben\r"); |
9 | uart_puts("E EEProm löschen\r"); |
10 | uart_puts("G Go\r"); |
11 | uart_puts(" Einstellungen:\r"); |
12 | uart_puts("O Oberer Grenzwert\r"); |
13 | uart_puts("U Unterer Grenzwert\r"); |
14 | uart_puts("Z Zeit eingeben\r"); |
15 | |
16 | uart_putc ('\r'); |
17 | }
|
Die UART Bibliothek (von Peter Fleury), die ich verwende scheine ich dabei zu überfordern, denn wenn ich ins per ISP ausgelesene hex File schaue stehen diese Menüpunkte ein zweites Mal am Ende des Quellcodeteils. Wenn ich drei dieser Menüpunktausgaben auskommentiere funktioniert alles richtig. Vielleicht läuft da irgendein Puffer durch die vielen hintereinander geschalteten Ausgaben über? Landet so was dann im Programmspeicher? Warum aber auch der Bootloader betroffen ist, ist mir schleierhaft. Gruß Mickey
Weil du dir mit den Strings den RAM vollknallst! guck dir mal an was progmem macht und wie mans nutzt. Diese Strings stehen im Flash und im RAM. Progmem Variablen sind nur im Flash.
Martin Wende schrieb: > Diese Strings stehen im Flash und im RAM. > Progmem Variablen sind nur im Flash. Ist doch wurscht, hier geht's nur um's Flash und dort werden die Strings auf alle Fälle stehen. @mickey Fragst Du eigentlich nur, oder hörst Du auch auf Ratschlage, die man Dir gibt ?
Wenn das Programm nach einem Reset nicht mehr geht, wie sieht es nach einem stromlosschalten aus. Geht es dann wieder? Wenn ja. würde ich eher auf den Watchdog tippen.
Ich hatte mit einem ATMega8 mit 8MHz und 115200 Zapplern nichts als Ärger. Nachdem ich etwas bescheidener geworden bin, gab's keine Probleme mehr.
Ein Posting des vollstaendigen Flashinhaltes waere ggf. hilfreich. (Vor und nach Fehlverhalten) MfG marixstorm
8Mhz und 115200 Baud passen nicht so gut zusammen - siehe Datenblatt des AVR. Ist Dir denn klar, dass der Bootloader nurch einen Reset Impuls gestartet werden muss? Dein Beitrag von 14:48 scheint anzudeuten, dass Du das Programm per Bootloader installierst, dann ausführst und dann nochmal installieren willst (ohne Reset dazwischen).
Bitte 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.