avr-gcc und .noinit

[Mehmet K. (mkmk)]

Servus allerseits
Vermutlich sind's mehr als 15 Jahre her, als ich zuletzt mit AVR-MCUs 
gearbeitet hatte.
Deshalb fühle ich mich so in etwa wie ein Fisch, den's aufs Land 
gespühlt hat.
Meine Arbeitsumgebung:
- Debian
- MATLAB X
- PICKIT 4
- avr-gcc (Toolchain_3.6.7_489) 5.4.0
- ATTiny 414

Die MCU ist meist im power-down und wird durch den Watschdog aufgeweckt.
Mein Wunsch wäre es, dass der Inhalt einiger Variablen erhalten bleibt, 
ohne dass ich dazu das EEprom verwenden muss.
Zu Testzwecken habe ich mir ein uint8_t mit _attribute_ ((section 
(".noinit"))) angelegt; aber diese wird bei jedem Neustart mit 0 
übersschrieben.

Wenn ich mit avr-objdump die elf-Datei mir angucke, sehe ich hingegen 
die Section .noinit.
Zuerst dache ich, der Debugger verfälsche das Ergebnis; aber auch ohne 
Debugger bleibt die LED dunkel.
Vermutlich ist irgendwas mit meinem Test nicht ganz koscher ... aber ich 
finde den Fehler nicht.

uint8_t test_val      __attribute__((section(".noinit")));
void DisableWDT(void) __attribute__((naked)) __attribute__((section(".init3")));

//=================================
// DisableWDT
//=================================
void DisableWDT(void) {
    wdt_disable();
}

//=================================
// Init
//=================================
void MyApp::Init(void) {

    //---------------------test start
    test_val++;
    if (test_val >= 3){
        Led.Init();
        Led.GreenOn();
        while(1){};
    }
    wdt_enable(WDTO_500MS);
    while(1) {};
    //---------------------test end
    ...

}

[Bauform B. (bauformb)]

Mehmet K. schrieb:
> uint8_t test_val __attribute__((section(".noinit")));

Lass mal den Linker die section selber anlegen; also probier mal

__attribute__ ((noinit));

[Mehmet K. (mkmk)]

Bauform B. schrieb:
> Mehmet K. schrieb:
>> uint8_t test_val __attribute__((section(".noinit")));
>
> Lass mal den Linker die section selber anlegen; also probier
> mal__attribute__ ((noinit));

src/others/app.cpp:17:41: warning: 'noinit' attribute directive ignored 
[-Wattributes]

[Johann L. (gjlayde)]

Attribut section(".noinit") ist schon ok.  Section .noinit folgt auf 
.bss, wird also nicht vom Startup-Code initialisiert; dieser 
initialisiert nur bis __bss_end, siehe

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/avr/lib1funcs.S;h=0870595111ad5b8121a57ee84a38994976c575d8;hb=cffa72fde8ce9c767e20c058892929d9c9b33ae7#l2432

Und default ld-Script setzt __bss_end vor den Anfang von .noinit:

  .bss  ADDR(.data) + SIZEOF (.data)   : AT (ADDR (.bss))
  {
     PROVIDE (__bss_start = .) ;
    *(.bss)
     *(.bss*)
     *(COMMON)
     PROVIDE (__bss_end = .) ;
  }  > data
   __data_load_start = LOADADDR(.data);
   __data_load_end = __data_load_start + SIZEOF(.data);
  /* Global data not cleared after reset.  */
  .noinit  ADDR(.bss) + SIZEOF (.bss)  :  AT (ADDR (.noinit))
  {
     PROVIDE (__noinit_start = .) ;
    *(.noinit .noinit.* .gnu.linkonce.n.*)
     PROVIDE (__noinit_end = .) ;
     _end = . ;
     PROVIDE (__heap_start = .) ;
  }  > data

Wenn also in einer .noinit-Variablen ein Wert drinne steht, dann von 
einem vorhergehenden Lauf, oder es steht ein (teilweise) zufälliger Wert 
drinne nach PowerUp Reset.

[Oliver S. (oliverso)]

Das vorhandene linkerscript müsste man allerdings mal anschauen, ob das 
tatsächlich auch so aussieht, wie das verlinkte.

Oliver

[Mehmet K. (mkmk)]

Oliver S. schrieb:
> Das vorhandene linkerscript

Keine Ahnung, wo man beim MPLAB das Linker-Skript findet. Aber wie 
bereits erwähnt: avr-objdump zeigt mir korrekt dieses eine Byte in der 
.noinit Sektion an.

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000000  00803f00  00803f00  00000458  2**0
                  ALLOC, LOAD, DATA
  1 .text         0000009a  00000000  00000000  00000094  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .noinit       00000001  00803f00  00803f00  00000458  2**0
                  ALLOC
  ...

[Max H. (nilsp)]

Oder poste Dein Linkscript.

[Motopick (motopick)]

> Oder poste Dein Linkscript.

> Keine Ahnung, wo man beim MPLAB das Linker-Skript findet.

Es ist schon bemerkenswert, dass man mit Dingen ausserhalb
von .code, .data und .bss operieren will, und dann nicht mal
das verwenderte Linkerscript vorzeigen kann.

Wenn es nicht in der Dokumentation steht, vielleicht einfach
mal eigeninitiativ danach suchen?

[B. W. (yesitsme)]

Wird der RAM eigentlich beim Power-down versorgt oder braucht man da 
einen weniger tiefen Schlafmodus?

[Mehmet K. (mkmk)]

Ja, beim Power-down bleibt die Stromversorgung erhalten.
Und gemäss Datenblatt:

Power-Down with full data retention

[Mehmet K. (mkmk)]

Wobei: z.Zt. knabbere ich am obigen Test herum. D.h., momentan kommt der 
power-down erst gar nicht zum Zuge.

[Norbert (der_norbert)]

Mal so aus der Hüfte geschossen…
Da ist aber nicht noch irgendwo ein vorgelagerter Bootloader der dir in 
die Suppe spuckt?

[Mehmet K. (mkmk)]

Nein, kein Bootloader.
Da ich schon längst mit Try-and-Error im Trüben fische, habe ich dieses 
noinit in eine c-Datei verlagert. Aber das hat's auch nicht gebracht.

[Mehmet K. (mkmk)]

Der Linker-Script ist die Datei avrxmega3.xn und befindet sich im Ordner 
/opt/microchip/xc8/v2.41/avr/avr/lib/ldscripts

Mein erster Gedanke war ein "Aha!", aber das scheint schon seine 
Richtigkeit zu haben.
Dann habe ich den Test-Code dahingehend geändert, dass ich auch in der 
init3 Sektion die Variable inkrementiere und gleich ein Restart 
durchführte.
Und siehe da: sie wurde nicht mit 0 überschrieben.
Gemäss der Online-Dokumentation von microchip (*) kommt nur init4 als 
Spielverderber in Frage.

.init4:
For devices with > 64 KB of ROM, .init4 defines the code which takes care of copying the contents of .data from the flash to SRAM. For all other devices, this code as well as the code to zero out the .bss section is loaded from libgcc.a.

Und hier bin ich am Ende mit meinem Latein.

(*) 
https://onlinedocs.microchip.com/pr/GUID-317042D4-BCCE-4065-BB05-AC4312DBC2C4-en-US-2/index.html?GUID-34931843-0F2B-49EE-A117-7AB61373F68D

[Johann L. (gjlayde)]

Wozu brauchst du eigentlich eine noinit-Variable? Nach Beendung des 
Sleep-Modes wird doch kein Reset ausgeführt, also was soll da noinit 
bringen?

[Mehmet K. (mkmk)]

Der power-down wird vom Watchdog beendet. Und das hat ein Reset zur 
Folge.

[Johann L. (gjlayde)]

Lass doch mal die Reset-Ursache mit ausgeben, die brauchst ja eh um 
test_val initialisieren zu können.  Steht in MCUSR (MCU Status Register) 
oder RSTFR (Reset Flag Register).

[Jörg W. (dl8dtl) (Moderator)]

Nicht vergessen, dass die Reset-Bits in MCUSR bei einem Reset nicht 
gelöscht werden. Nur bei Power-on werden diese alle gelöscht (und dann 
das entsprechende Flag gesetzt).

Um den Wachhund anschließend abschalten zu können, musst du das 
entsprechende Reset-Bit unbedingt löschen, sonst beißt der gleich wieder 
zu.

[Peter D. (peda)]

Johann L. schrieb:
> Nach Beendung des
> Sleep-Modes wird doch kein Reset ausgeführt

Leider doch. Bei den neueren AVRs ist der Watchdoginterrupt wieder 
entfernt worden.
Man kann aber den PIT zum Aufwachen nehmen mit den internen 32kHz ULP.

Über Reset zu gehen, finde ich auch unschön. Denn da gehen ja wieder 
alle IOs kurz in tristate. Z.B. eine LED würde kurz flackern, ein Magnet 
kurz abfallen.

[Mehmet K. (mkmk)]

Jörg W. schrieb:
> Nicht vergessen, dass die Reset-Bits in MCUSR bei einem Reset nicht
> gelöscht werden.

Okay, diesen Flag hatte ich nicht beachtet. Beim Attiny414 ist das im 
Register STCTRL.RSTFR versteckt.
Tat aber insofern nicht weh, weil das Watchdog-Register im OFF-Zustand 
daherkam. Wie es dem auch sei: an meiner ganzen Misere hat sich leider 
nichts geäendert.
Ich musste aber feststellen, dass der Attiny von der ganzen Toolchain 
nicht korrekt unterstützt wird.

wdt_enable(WDTO_500MS);

führt zum Bsp. zu einer 125ms Verzögerung weil

wdt.h
#define WDTO_500MS  5

Auch sind die Werte 4 und 8 Sekunden auskommentiert.
Mit anderen Worten, man muss mit

_PROTECTED_WRITE(WDT.CTRLA, WDT_PERIOD_512CLK_gc);

arbeiten. Vermutlich gibt es noch weitere Ungereimtheiten, unter einer 
denen mein Problem vergraben liegt. Also ich geb's auf. Das Ganze 
übersteigt bei weitem meine Fähigkeiten.

[Jörg W. (dl8dtl) (Moderator)]

Mehmet K. schrieb:
> Ich musste aber feststellen, dass der Attiny von der ganzen Toolchain
> nicht korrekt unterstützt wird.

Naja, den Watchdog-Support hat dafür jetzt noch keiner angepasst.

Hat aber mit dem (Nicht-)Funktionieren von .noinit nichts direkt zu tun.

Ich habe von diesen neuen Tinys gerade kein Board zur Hand (irgendwo 
muss ich noch einen ATtiny1634 oder sowas liegen haben, aber ohne 
Board), insofern kann ich darauf nicht testen. Allgemein AVR0 habe ich 
aber was (AVR128DA48 oder so), um da was zu probieren.

[Oliver S. (oliverso)]

Jörg W. schrieb:
> Allgemein AVR0 habe ich
> aber was (AVR128DA48 oder so), um da was zu probieren.

Da reicht es doch, sich im Startup-Code anzuschauen, ob der 
.noinint-Bereich genullt wird oder nicht. Dafür braucht es keine 
physische hardware zum testen.

Oliver

[Jörg W. (dl8dtl) (Moderator)]

Dafür könnte Mehmet natürlich einfach sein ELF-File hier hochladen.

Schätzungsweise wird er nicht genullt, und das Problem liegt ganz 
woanders.

[Mehmet K. (mkmk)]

Mein Hinweis wegen dem Watchdog war nur als Beispiel angedacht gewesen. 
Es sind mir noch ein paar andere Ungereimheiten aufgefallen; aber wegen 
meiner Aus-Zeit von mehr als 15 Jahren dachte ich stets, es liege ein 
Missverständis meinerseits vor.

Auf den power-down möchte ich sehr ungern verzichten, weil bei meinem 
Testaufbau es mir nicht gelungen ist, den Stromverbrauch zu messen.
Ich werde vermutlich mein Problem mit dem Periodic Interrupt Timer des 
RTC
lösen. Der Watchdog wäre zwar eleganter und einfacher gewesen ... aber 
was soll's.

[Mehmet K. (mkmk)]

Die Elf-Datei als Anhang

[Oliver S. (oliverso)]

Mehmet K. schrieb:
> Die Elf-Datei als Anhang

Gibt es dazu auch den passenden Sourcecode?

Oliver

[Jörg W. (dl8dtl) (Moderator)]

Mehmet K. schrieb:
> Der Watchdog wäre zwar eleganter und einfacher gewesen ... aber was
> soll's.

Ein Watchdog, der immer einen Reset schmeißt? Finde ich nicht. Beim 
ATmega128RFA1 habe ich ihn für ebendiesen Zweck (Aufwachen aus dem 
Sleep) schon benutzt, aber im Interrupt-Modus. Schade, dass der bei den 
neuen AVR0 nun wieder entfallen ist. Reset macht ziemlich viel kaputt, 
wie Peter oben schon schrieb.

[Jörg W. (dl8dtl) (Moderator)]

Oliver S. schrieb:
> Gibt es dazu auch den passenden Sourcecode?

Wofür sollte der wichtig sein, wenn es um die Analyse des 
Startup-Verhaltens geht? Der entsprechende Code kommt eh aus der 
Bibliothek.

[Mehmet K. (mkmk)]

Jörg W. schrieb:
> Schade, dass der bei den neuen AVR0 ...

Ich weiss nicht, ob das von Bedeutung ist, aber der ATTiny414 ist 
Mitglied der AVR 1-Serie.

[Jörg W. (dl8dtl) (Moderator)]

OK, ich hätte AVR0/1 schreiben sollen. ;-) Ist ja bei all diesen Teilen 
nicht mehr da, der Watchdog-Interrupt.

[Jörg W. (dl8dtl) (Moderator)]

OK, mein Fazit: Microchip hat da was am Startup-Code der avr-libc herum 
gepfuscht. Offenbar wollen sie mehre mögliche bss-Segmente unterstützen 
und legen nun eine Map für die einzelnen Segmente im Flash ab, statt 
(wie original avr-libc) diese direkt durch den Linker in den Code 
eintragen zu lassen. (Dabei haben sie nicht einmal verstanden, warum man 
globale Symbole mit zwei Unterstrichen beginnen sollte …)

Jedenfalls haben sie auf diese Weise dein .noinit kaputt gemacht, weil 
sie mit dem Ausnullen des vermeintlichen bss ab 0x3f00 (RAM-Start) 
beginnen.

Mach ein Ticket bei Microchip auf dafür. Sie haben es ja auch nicht 
nötig, ihre Änderungen ins avr-libc-Projekt zurück zu spielen. Weiß 
nicht, ob sie irgendwo den Sourcecode für ihre Änderung liegen haben 
oder rausgeben, aber sie sollen bitteschön jetzt ihr Gemurkse selbst 
supporten.

[Jörg W. (dl8dtl) (Moderator)]

Achso: wenn du für das Ticket eine englische Beschreibung brauchst, 
schreibe ich die dir gerne. Ich gebe mir auch Mühe, nicht so angepisst 
zu klingen. ;-)

Aber erzeuge dafür bitte ein minimales Beispiel, mit dem deren Support 
das Problem nachvollziehen kann, also irgendwas mit nur zwei Variablen 
und 'ner blinkenden LED oder so, und bitte auch in C, nicht C++.

[Mehmet K. (mkmk)]

Jörg W. schrieb:
> Mach ein Ticket bei Microchip auf dafür
Okay.

Jörg W. schrieb:
> nicht so angepisst zu klingen
Keine Sorge.

Falls Du es aus dem Ärmel schütteln kannst: Ein Link für die 
Ticket-Anlaufstelle?

[Jörg W. (dl8dtl) (Moderator)]

Mehmet K. schrieb:
> Falls Du es aus dem Ärmel schütteln kannst: Ein Link für die
> Ticket-Anlaufstelle?

Nee, hab ich auch nicht. Solltest du aber fündig werden. Landest dann 
sicher irgendwo in Indien, wo du dem Supporter als erstes nachweisen 
musst, dass es nicht deine eigene Blödheit war. Daher ein 
nachvollziehbares Beispiel.

[Mehmet K. (mkmk)]

Okay, erledigt. Die Anlaufstelle ist http://support.microchip.com

Jörg, vielen Dank für Deine Hilfe. Dank Dir muss ich jetzt nicht mehr 
mit gesenktem Kopf durch das Office schleichen, weil ich dachte, das 
Fehlverhalten beruhe auf meinem Fehler :)

[Johann L. (gjlayde)]

Mehmet K. schrieb:
> - MATLAB X
> - avr-gcc (Toolchain_3.6.7_489) 5.4.0

Wenn Mikrochip da wirklich an den Tools rumgemurxt hat, ist die Frage, 
warum nicht eine orgiginale Toolchain ohne 
Microchip-Verschlimmbesserung?

[Mehmet K. (mkmk)]

Wie ich in meiner Einganspost erwähnt habe: seit mehr als 15 Jahren habe 
ich mit den AVRs nichts mehr gemacht. Deshalb erschien es mir am 
einfachsten, etwas aus einem Guss zu installieren und mit Hilfe meiner 
alten Sources und  copy&paste etwas schnell zusammenzustellen. Okay, 
"schnell" ist was anderes.

Wenn Du mir also einen Link hast, mit dessen Hilfe ich ohne viel 
Klimmzüge eine stabile Toolchain erhalten kann: sehr gerne!

[Johann L. (gjlayde)]

Ich bau die Tools immer selbst.  Und unter linux gibts auch GNU Tools 
for AVR als "gcc-avr", "binutils-avr" und "avr-libc" wobei das GCC 
v5.4.0 ist.

[Wilhelm M. (wimalopaan)]

Johann L. schrieb:
> Ich bau die Tools immer selbst.  Und unter linux gibts auch GNU Tools
> for AVR als "gcc-avr", "binutils-avr" und "avr-libc" wobei das GCC
> v5.4.0 ist.

Du meinst wahrscheinlich ein Debian-Derivat?

Bei Arch-Linux ist es avr-gcc 12.2.0

[Johann L. (gjlayde)]

Ubuntu.

Wilhelm M. schrieb:
> Bei Arch-Linux ist es avr-gcc 12.2.0

Wegen https://gcc.gnu.org/PR90706 würde ich einen großen Bogen um v9, 
v10, v11 und v12 machen.

Und "eigene" Toolchain oder aus einer Distro sind i.d.R plain vanilla 
und ohne Device-Support für neuere Devices wie ATtiny414: Speziell 
ATtiny414 wird erst ab v8 (Release 2018) offiziell unterstützt.

Für ältere Versonen besorgt man sich ein Device Pack, z.B. von

http://packs.download.atmel.com/

Die .pack-Dateien sind im zip Format gespeichert, z.B.:

> jar tf Atmel.ATtiny_DFP.2.0.368.atpack | grep 414
gcc/dev/attiny414/avrxmega3/short-calls/crtattiny414.o
gcc/dev/attiny414/avrxmega3/short-calls/libattiny414.a
gcc/dev/attiny414/device-specs/specs-attiny414
include/avr/iotn414.h
xc8/avr/device-specs/specs-attiny414
xc8/avr/include/avr/iotn414.h
xc8/avr/lib/avrxmega3/short-calls/crtattiny414.o
xc8/avr/lib/avrxmega3/short-calls/libattiny414.a

Wie man die Device-Packs verwendet findet man hier im Forum, das wurde 
schon x mal durchgenudelt.

-mmcu=avrxmega3 gibt's auch erst ab v8, fur ältere Versionen des 
Compilers bis runter zu v5.4.0 muss man auf avrxmega2 abbilden, und noch 
ältere Versionen können garnicht auf ATtiny414 gepimpt werden.

[Jörg W. (dl8dtl) (Moderator)]

Johann L. schrieb:
> Wenn Mikrochip da wirklich an den Tools rumgemurxt hat, ist die Frage,
> warum nicht eine orgiginale Toolchain ohne
> Microchip-Verschlimmbesserung?

Ich würde mal sagen, dass es mit dem öffentlichen Code funktioniert. 
Habe jetzt keinen passenden Controller, das nachzuvollziehen, aber ich 
sehe folgende Effekte (GCC 11.2.0, avr-libc mehr oder minder aktueller 
Entwicklungsstand):

* nur .noinit-Variable, kein .bss und .data: es wird keinerlei 
RAM-Initialisierung überhaupt eingebunden, damit bleibt die 
.noinit-Variable unangetastet
* zusätzlich noch .bss und .data Dummies eingebaut: diese landen dann am 
Anfang des RAMs und werden mit den normalen Schleifen initialisiert; die 
.noinit-Variable steht dahinter und wird von den Schleifen nicht 
angefasst

Sollte also funktionieren (bis auf das schon genannte falsche 
WDT-Timing).

Edit: habe mein Testfile mal angehängt.

[Mehmet K. (mkmk)]

Leider nicht. Bei mir bleibt die Led dunkel.

[Jörg W. (dl8dtl) (Moderator)]

Das wundert mich bei deiner Toolchain jetzt nicht so richtig. ;-)

Hier noch das ELF-File (in dem Falle ohne -DINCLUDE_DATA).

[Mehmet K. (mkmk)]

Jörg W. schrieb:
> Das wundert mich bei deiner Toolchain jetzt nicht so richtig.

Irgendein Vorschlag, wie ich diesen (mit einfachen Mitteln) upgraden 
kann?

[Jörg W. (dl8dtl) (Moderator)]

Mehmet K. schrieb:
> Jörg W. schrieb:
>> Das wundert mich bei deiner Toolchain jetzt nicht so richtig.
>
> Irgendein Vorschlag, wie ich diesen (mit einfachen Mitteln) upgraden
> kann?

Ich habe keine rechte Idee, wo die wie und was vergurkt haben. Da ich 
kein Windows-Nutzer bin, kann ich dir nicht einmal sagen, wo die ihre 
Toolchain liegen haben.

Hast du denn das ELF-File von mir mal getestet? Also, ich weiß natürlich 
nicht, wo bei dir die LED hängt ;-). Da du den Teil des Codes nicht 
gepostet hattest, hab' ich da einfach mal PB0 mit einer high-aktiven 
"LED" reingesetzt. Ich kann dir das aber auch noch für einen beliebigen 
anderen Port und andere Polarität bauen.

[B. W. (yesitsme)]

Mehmet K. schrieb:
> Ja, beim Power-down bleibt die Stromversorgung erhalten.
> Und gemäss Datenblatt:
>

> Power-Down with full data retention
>

Kannst du das Datenblkatt einmal verlinken bitte?

[Mehmet K. (mkmk)]

Jörg W. schrieb:
> Da ich kein Windows-Nutzer bin
Heyyy! Ich auch nicht (mehr). :)
In meiner Eingangspost hatte ich erwähnt, dass ich mit Debian arbeite.

B. W. schrieb:
> das Datenblkatt einmal verlinken
https://ww1.microchip.com/downloads/en/DeviceDoc/ATtiny212-214-412-414-416-DataSheet-DS40002287A.pdf
2. Seite

[Mehmet K. (mkmk)]

Jörg W. schrieb:
> Hast du denn das ELF-File von mir mal getestet?

Gestern abend fand ich keine Möglichkeit via MPLab IDE das ELF-File zu 
testen. Heute morgen nochmals mit klarem Kopf danach gesucht, aber 
anscheinend ist sowas nicht vorgesehen.

[Wilhelm M. (wimalopaan)]

Johann L. schrieb:
> Ubuntu.
>
> Wilhelm M. schrieb:
>> Bei Arch-Linux ist es avr-gcc 12.2.0
>
> Wegen https://gcc.gnu.org/PR90706 würde ich einen großen Bogen um v9,
> v10, v11 und v12 machen.

Bezogen auf den Testcase in PR90706 ist der gcc-13.0.1 wieder optimal. 
Bei Deinen zusätzlichen Testcases ist er wieder auf dem Niveau von 
gcc-8.5.

Betrachte ich "echte" größere Projekte, so stelle ich zwischen 
gcc-12.2.0 und gc-13.0.1 Unterschiede fest, aber in beide Richtungen: 
mal ist der eine besser, mal der andere (bezogen auf die Größe).

[Jörg W. (dl8dtl) (Moderator)]

Mehmet K. schrieb:
> Gestern abend fand ich keine Möglichkeit via MPLab IDE das ELF-File zu
> testen. Heute morgen nochmals mit klarem Kopf danach gesucht, aber
> anscheinend ist sowas nicht vorgesehen.

avrdude -c <deinprogrammertyp> -p attiny414 -U test.elf

[Jörg W. (dl8dtl) (Moderator)]

Und ja, wenn du Linux benutzt, dann einfach mal selbst compilieren, wie 
Johann schon schrieb. Ist keine Raketenwissenschaft.

[Mehmet K. (mkmk)]

Auf der Microchip-Seite fand ich eine neuere Version und damit hat 
noinit nun endlich seine Aufgabe richtig erfüllt.
avr-g++ (AVR_8_bit_GNU_Toolchain_3.7.0_1796) 7.3.0

https://www.microchip.com/en-us/tools-resources/develop/microchip-studio/gcc-compilers

[Oliver S. (oliverso)]

Ich habs mal mit der Windows-Version probiert, die nutzt
GNU C++ (AVR_8_bit_GNU_Toolchain_3.6.2_1778) version 5.4.0 (avr)

Egal, was ich auch probiert habe, die .noinit-section liegt immer hinter 
der .bss-section, und wird auch nicht genullt. Auch nutzt der diese 
seltsame Adresstabelle im Flash nicht, die Adressen kommen wohl direkt 
aus dem linker.

Keine Ahnung, was die da für Linux zusammengebastelt haben.

Oliver

[Harald K. (kirnbichler)]

Moby, man erkennt Dich an Deinem Stil.