Forum: Mikrocontroller und Digitale Elektronik Wieso zerstört mir mein Programm den Bootloader (atmega8)


von Michael J. (mickey2)


Lesenswert?

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

von Michael D. (etzen_michi)


Lesenswert?

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.

von Michael J. (mickey2)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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.

von Michael J. (mickey2)


Lesenswert?

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

von MWS (Gast)


Lesenswert?

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.

von Michael J. (mickey2)


Angehängte Dateien:

Lesenswert?

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

von Peter D. (peda)


Lesenswert?

Sofern es nicht um extrem sparsamen Batteriebetrieb geht, sollte das BOR 
immer an sein.

von Georg G. (df2au)


Lesenswert?

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...

von Heya ho. (Gast)


Lesenswert?

Scheint das uart empfaengt nichts. Allenfalls wurde das Uart 
unvollstaendig initialisiert.

von Michael J. (mickey2)


Lesenswert?

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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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.

von MWS (Gast)


Lesenswert?

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 ?

von Fred (Gast)


Lesenswert?

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.

von amateur (Gast)


Lesenswert?

Ich hatte mit einem ATMega8 mit 8MHz und 115200 Zapplern nichts als 
Ärger. Nachdem ich etwas bescheidener geworden bin, gab's keine Probleme 
mehr.

von marixstorm (Gast)


Lesenswert?

Ein Posting des vollstaendigen Flashinhaltes waere ggf. hilfreich.
(Vor und nach Fehlverhalten)

MfG marixstorm

von Stefan (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.