avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] noinitdata section ?


From: Theodore A. Roth
Subject: Re: [avr-libc-dev] noinitdata section ?
Date: Tue, 27 Aug 2002 09:02:45 -0700 (PDT)

On Wed, 28 Aug 2002, daniel_laptop wrote:

:) Has any of the noinitdata section been implemented ?
:) If so - where can I find info. (source or doc file etc.) ?
:) If not - is noinitdata going to be looked at ?

Well, I just grep'ed for 'noinitdata' through all the files in binutils,
gcc and avr-libc (all cvs, about a week old) and didn't see anything.

Marek would know more about this than me.

:)
:) One suggestion for noinitdata is a means (generated memory map file ? /
:) memory address attribute ?) to be able to keep (access) the data stored
:) in nvram after an in system flash software upgrade of the MCU. (Or is
:) this already in the making ;-)

Are you talking about flash or eeprom (both are nvram ;). I don't think
that you can erase anything but the entire flash at once. _Maybe_ a block,
but definitely not an arbitrary sized one. For example, you can erase
everything (flash, that is) but the boot block with a chip erase, but you
have to set some fuses to enable this.

If you want to have something remain in memory after a hard/soft reboot,
you should use the eeprom. That's what it's there for any ways. You can
pre-program the eeprom before you flash the program space too.

[Note to developers: we need to document how to pre-program the eeprom!]

On another note, the documentation for the various .section directives is
lacking. What are all the sections available to the user? I have only used
.init[0-9] so far and it appears...

avr-libc-cvs/crt1/gcrt1.S:102:  .section .init0,"ax",@progbits
avr-libc-cvs/crt1/gcrt1.S:120:  .section .init2,"ax",@progbits
avr-libc-cvs/crt1/gcrt1.S:134:  .section .init4,"ax",@progbits
avr-libc-cvs/crt1/gcrt1.S:174:  .section .init9,"ax",@progbits

...that gcrt1.S uses 0,2,4,9 for stuff (weakly bound??). Can the user
safely override these? Should they?

I think I will stub out a new dox file for this. I don't know the answers
(yet...), but the stub will be a reminder that it needs to be done.

Ted Roth





reply via email to

[Prev in Thread] Current Thread [Next in Thread]