Habe ich ein Problem mit dem Programmspeicher???

[Kera]

Hallo, ich bräuchte wiedermal eure Hilfe!

Ich arbeite mit dem ATmega8535, dieser besitzt 8k Programmspeicher!

Wenn ich nun bei meinem Programm 3 Zeilen dazu schreibe, geht das Programm auf der µc-Platine nicht mehr, obwohl mir das Compiler Fenster das hier ausspuckt:



> "C:\WinAVR\utils\bin\make.exe" all

-------- begin --------
avr-gcc (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Size before:
regler.elf :
section size addr
.text 6564 0
.data 0 8388704
.bss 174 8388704
.noinit 0 8388878
.eeprom 0 8454144
.stab 8064 0
.stabstr 3218 0
Total 18020



C:\WinAVR\utils\bin\make.exe: *** Warning: File `protokoll.c' has modification time in the future (2006-03-13 14:53:02 > 2006-03-13 14:53:00)

Compiling: protokoll.c
avr-gcc -c -mmcu=atmega8535 -I. -g -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=protokoll.lst -std=gnu99 -Wp,-M,-MP,-MT,protokoll.o,-MF,.dep/protokoll.o.d protokoll.c -o protokoll.o

Linking: regler.elf
avr-gcc -mmcu=atmega8535 -I. -g -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=regler.o -std=gnu99 -Wp,-M,-MP,-MT,regler.o,-MF,.dep/regler.elf.d regler.o uart.o timer8.o adc.o regler_funct.o protokoll.o pwm.o --output regler.elf -Wl,-Map=regler.map,--cref -lm

Creating load file for Flash: regler.hex
avr-objcopy -O ihex -R .eeprom regler.elf regler.hex

Creating load file for EEPROM: regler.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex regler.elf regler.eep

Creating Extended Listing: regler.lss
avr-objdump -h -S regler.elf > regler.lss

Creating Symbol Table: regler.sym
avr-nm -n regler.elf > regler.sym

Converting to AVR Extended COFF: regler.cof
avr-objcopy --debugging --change-section-address .data-0x800000 --change-section-address .bss-0x800000 --change-section-address .noinit-0x800000 --change-section-address .eeprom-0x810000 -O coff-ext-avr regler.elf regler.cof
Discarding local symbol outside any compilation unit: _exp_100
Discarding local symbol outside any compilation unit: _exp_200
Discarding local symbol outside any compilation unit: table_exp
Discarding local symbol outside any compilation unit: _exp_300
Discarding local symbol outside any compilation unit: _exp_200_1
Discarding local symbol outside any compilation unit: _log_10
Discarding local symbol outside any compilation unit: _log_20
Discarding local symbol outside any compilation unit: table_log
Discarding local symbol outside any compilation unit: .do_copy_data_start
Discarding local symbol outside any compilation unit: .do_copy_data_loop
Discarding local symbol outside any compilation unit: .do_clear_bss_start
Discarding local symbol outside any compilation unit: .do_clear_bss_loop

Size after:
regler.elf :
section size addr
.text 6636 0
.data 0 8388704
.bss 174 8388704
.noinit 0 8388878
.eeprom 0 8454144
.stab 8112 0
.stabstr 3245 0
Total 18167



Errors: none
-------- end --------

> Process Exit Code: 0



Wie man hier sieht, ist .text erst auf 6636, normaler weise müsste ich doch bis 8000 gehen können, oder??
Komischer weise geht es immer dann nicht, wenn .text über 6600 springt! Warum??

.text steht doch für die Programmzeilen(COde) oder??

MFG

[ogni42]

Die Berechnung Flash/SRAM geht wie folgt:

.text + .data = Flash
.data + .bss + .noinit = SRAM

.text = Programmcode
.data = initialisierte Variablen wie Strings, etc.
.bss = uninitialisierte Variablen
.eeprom = daten im EEPROM
.stab/.stabstr = IMHO (!) Symboltabelle und Symbolnamen (nur für debugging verwendet).

In Deinem Fall flash = 6636Bytes. Ist also noch deutlich kleiner als 8192.

Mögliche Erklärung: Bootloadersektion ist auf einen grossen Wert gesetzt.

Alternativer Workaround. Mal mit -O2 oder -Os kompilieren, dann sollte der Flashverbrauch sinken.

[ogni42]

Nach Blick ins Datenblatt nehme ich an, dass Dein Bootloadersize auf default = 1024 Byte steht. Eigentlich sollte es dann auch noch passen.

[Kera]

Danke für deine Antwort!

Aber wie kann ich die Bootloadersize(Bootloadersektion) verändern??
Geht das im Programm, oder ist das beim Compiler zu verändern?

[ogni42]

Steht im Datenblatt. Du musst die Bootsize Bits in den Fusebytes beim Brennen entsprechend setzen - in Deinem Fall auf 11 was zu einer Bootpage von 128Bytes (statt 1024 Bytes) führt.

-O2 (als Compileroption, statt -O0) solltest Du aber vorher verwenden, um zu sehen, wieviel Platz wirklich benötigt wird. Das senkt das Risiko die Fusebits zu vermasseln :)

[linux_80]

Hallo,
die grösse des Bootsektors hat doch erstmal nix damit zu tun, dass man da nix reinflashen kann, erst wenn man die Lockbits setzt wirkt sich die grösse aus.
Zumindest beim M8 kann ich den ganzen Flash vollschreiben, wie soll man sonst den Bootloader da hin bekommen !?

@Kera,
wenn Du schon am neu flashen bist, kannst Du mal einen kompletten Reset des µC machen (Chip erase), dann sollten die Fusebits wieder in Ausgangsstellung sein, falls das eine oder andre Lockbit doch gesetzt sein sollte.
Mit welchem Programm willst Du Flashen ?

[Kera]

Ich arbeite mit dem Programers Notepad und der entwicklungsumgebung WinAVR 20040404!!!

Warum??

Wie kann ich die Fusebits überhaupt setzen, oder lesen??? Kenn mich da nicht aus!!!

MFG

[ogni42]

@linux_80: Stimmt natürlich :oops:

Kera, kannst Du bitte mal genau das Problem beschreiben was nicht geht?

Meldet dir Dein Flashprogramm, dass die Datei zu groß ist?

[askazo]

Zu den Fuses:
Hast Du das AVR-Studio? Dort klickst Du in der Symbolleiste auf den kleinen IC, wo AVR draufsteht. Von dort aus kannst Du auch flashen.
Wenn Du auf die Registerkarte 'Fuses' klickst, siehst Du alle Einstellungen der Fusebits und kannst sie dort auch ändern.

Schalte mal die oberste Fuse aus (AT90S4434/8535 compatibility mode).
Vielleicht macht das Ärger.

Gruß,
askazo