avr-gcc och volatile .noinit

[stekern]

Jag har tillbringat morgonen med att felsöka en klockrutin som ibland till synes går baklänges.
(jag tror inte den går baklänges, utan att en minnesplats ändras felaktigt någonstans)
Det jag har är en atmega644p med en 32khz kristall kopplad till timer2.
Sen har jag en variabel som räknas upp för varje sekund i ett interrupt.
Kruxet är att när jag deklarerar den som .noinit så uppstår problemet, men inte om jag inte deklarerar den som .noinit

såhär deklarerar jag den som noinit

Kod: Markera allt

static volatile dword elapsed_time __attribute__ ((section (".noinit")));

och såhär utan

Kod: Markera allt

static volatile dword elapsed_time;

interruptet ser ut såhär:

Kod: Markera allt

ISR(TIMER2_OVF_vect)
{  
  elapsed_time++;
}

Är det nån som har några inflikningar till det här, kan en .noinit inte vara volatile?
eller kan det vara något annat som görs att minnet "råkas" användas till annat?

[Icecap]

Om man deklarerar "static" utanför en avgränsat rutin (t.ex. i en C-fil) "finns" den bara i den fil.

Förklara gärna varför det är viktigt att den sparas i "noinit"-sektionen och varför du deklarerar den som "static".

[stekern]

Variabeln skall bara används i denna filen.
Anledningen till .noinit är att klockvärdet skall bevaras efter en reset (om inte strömförsörjningen har brutits).

[SvenW]

Det står så här i en not i user-manual:

"Because of the Harvard architecture of the AVR devices, you must manually add 0x800000 to the address you pass to the linker as the start of the section. Otherwise, the linker thinks you want to put the .noinit section into the .text section instead of .data/.bss and will complain."


Kan du kontrollera var .noinit hamnar?

Se vidare i
http://www.nongnu.org/avr-libc/user-man ... tions.html

[stekern]

Det den där kommentaren säger är väl "om du vill sätta en egen plats för .noinit så måste du addera 0x800000 till adressen när du ger den till linkern"?
Jag ska kika lite mer på minnesplatserna som elapsed_time hamnar på med .noinit och utan, återkommer med det.

[stekern]

Jag kollade upp var elapsed_time hamnar med .noinit påslagen, och den ligger på adresserna 0x06F7,0x06F8,0x06F9,0x06FA

ur .lss filen

Kod: Markera allt

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         0000000e  00800100  00008d28  00008dbc  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  1 .text         00008d28  00000000  00000000  00000094  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .bss          000005e9  0080010e  0080010e  00008dca  2**0
                  ALLOC
  3 .noinit       00000004  008006f7  008006f7  00008dca  2**0
                  ALLOC

så det verkar ju ok.

[snigelen]

Jag har provkört lite på en m644p men kan inte se några konstigheter. Den beter sig vettigt i båda fallen och behåller värdet vid reset då variabeln ligger i .noinit.

[stekern]

Jo, den beter sig vettigt för mig med lite beroende på vad man gör.
En möjlighet är ju att det finns någon bugg i koden som gör att minnesplatsen skrivs över av misstag, jag får fortsätta att forska vidare.

[stekern]

Det är definitivt någon bugg någonstans, samma problem uppstår även om .noinit inte är satt, det tar bara längre tid.

[Icecap]

Det är en sak i det hela som stör mig: Du förväntar att processorn ska resettas lite hur som helst och ändå köra vidare med "giltiga" värden?
Är din hårdvara så instabil? Eller är programmet så instabilt?

Om det är för att WDT resettar processorn är det ju något fel som ska hittas.

[stekern]

Jag förväntar mig inte att den skall resettas lite hursomhelst, varken hårdvaran eller mjukvaran gör så att processorn okontrollerat resettas.

Den fulla bakgrundshistorien är denna:
Jag håller på och portar ett program (skrivet av nån annan) från IAR till avr-gcc och i IAR-koden var denna satt till noinit, därav satte jag den till .noinit även i den portade koden.
Sen trodde jag mig upptäcka att detta medförde problem (därav frågan här), men nu har det ju visat sig att det är nåt annat som spökar.

Sen om jag nu slutligen behöver att ha denna satt till .noinit eller inte är inte säkert, men jag vill helst gå till botten med problem.

Men sen kan det väl finnas mängder med anledningar till att vilja kontrollerat resetta en processor, på dig låter dig som om reset = fail.

[Icecap]

Ja, jag anser faktisk att en reset är det samma som att det är något fel i hårdvara eller program, jag har inte än upplevd någon gång där en reset är användbar och jag har ändå programmerat en hel del kommersiella produkter + mycket annat.

[eqlazer]

Skulle nog vilja hävda tvärt om, att reset kan vara riktigt användbart och ibland nödvändigt.

Ibland måste man ha ett känt tillstånd på all hw och då är reset ett snabbt och enkelt sätt att åstadkomma det på. Vissa mcu har tex funktion att kunna resetta alla hw-moduler men låter programpekaren vara oförstörd, andra har inte detta och "hård" reset är den enda vägen.

Ett inte helt ovanligt scenario där reset används är då en applikation körs och man ska ner i bootloader för att köra swdl.

Givetvis finns det oftast andra sätt att utföra reset-liknande funktionalitet, men man ska nog inte rakt avfärda det som att det endast ska användas vid fel.

[v-g]

Jag tror att iskapsylen menar att en reset aldrig ska förekomma "windows style" dvs som ett led när tex något gått fel eller för att processorn inte gör vad den ska.

Alla register osv skall man ju hålla koll på ändå och de skall initieras där tillståndet kan tänkas vara okänt.

Ska man byta kod/programmera om(byta firmware typ) är man ju inte i normal drift.

[eqlazer]

Men det är ju då det är som mest användbart med reset, en watchdog fyller ju sin funktionalitet (vilket oftast är en reset vid hw/sw-fel). I en perfekt värld så ska det inte behöva inträffa att wdtn går in, men i kritiska applikationer så vill man ha både hängslen och livrem. Vissa saker kan en reset lösa och jämfört med ett låst program så kan en omstart vara skillnaden med en bil som startar eller inte.

Nej vad som är normal drift och inte kan ju diskuteras, det vara bara det att jag inte höll med om att det inte finns fall då reset kan vara användbart. Däremot vad som är mest rätt beror ju helt på applikationen.