Wieso zerstört mir mein Programm den Bootloader (atmega8)

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

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

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.