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

[daniel_laptop]

"Theodore A. Roth" wrote:

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

OK so "noinitdata" is all possible future stuff then ;-)

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

I am talking about external device battery backed SRAM
(or nvram - www.simtek.com
http://www.simtek.com/Technology/SimtekQuantumTrap.pdf
- www.zmd.de   http://www.zmd.de/nvsram_overview.html  )
That can be programed once by itself and then normal runtime changes
and if flash MCU software upgrade still keep data.
eg counter of something since board installed.
(to many changes for normal eeprom).


to quote emails
 http://avr.jpk.co.nz/pipermail/avr-gcc-list/2002-January/001322.html
>> Besides C++ support, one thing I'd like to add is a new ".noinitdata"
>> section, above BSS, for global variables that are not initialized by
>> C startup code (for data to survive across external or WDT reset).

If keeping data through MCU flash software upgrade it might ? be
best to have noinitdata at the end of external ram.
(option to set location of noinitdata)

 http://avr.jpk.co.nz/pipermail/avr-gcc-list/2002-May/001841.html
>> and if you have ideas what should be changed in the new linker scripts,
>> now is good time to tell me.  Things I already know of:
>>
>>  - C++ support (section for constructor list)
>>  - .init0 ... .init7 code sections so make it easier for the user to
>>   insert code to execute early on startup
>>  - .noinitdata section, like BSS but not cleared after reset, for data
>>    in SRAM with battery backup, use
__attribute__((section(".noinitdata")))
>>    in C declarations of such variables
>>  - __heap_start and __heap_end symbols for use by malloc (heap end might
>>    not always be below the stack as is assumed now - for example,
ATmega161
>>    errata requires stack in internal SRAM if external SRAM is used, and
>>    internal SRAM is faster so it's a good idea anyway).

I hope that as i get more familiar with avr-libc,binutils,gcc
that I can help in creating "noinitdata"

Daniel