Felaktig variabeldeklaration = nära katastrof! (AVR)

[jesse]

Jag har haft ett projekt ganska länge, när jag råkade upptäcka att en variabel som skulle ligga i eeprom istället hamnade i SRAM. Eftersom jag bara använde pekare till variabeln i eeprom läs och skriv -funktionerna så innebar det att jag skrev över data på fel ställe i eepromet! Hur gick detta till då? Jo kolla här:

Kod: Markera allt

struct settings { ... bla bla.. };
struct klocka { ... bla bla.. };
struct hw_setup { ... bla bla.. };

// SRAM data - globala variabler
struct settings set = { 0 };
struct klocka clock  = { 0 };
struct hw_setup hardware = { 0 }

// EEPROM data
struct settings EEMEM ee_set = { 0 };
struct klocka EEMEM ee_clock  = { 0 };
struct EEMEM hw_setup ee_hardware = { 0 };

eeprom_write_word(&ee_hardware.modules, hardware.modules);

Här ser vi att jag vill spara en variabel i eeprom. Men vad händer?
Jag kollar i filen projekt.map:

Kod: Markera allt

.eeprom        0x00810000      0x2b8 main.o
                0x00810000                ee_reset_count
                0x00810002                ee_set
                0x00810030                ee_clock
                0x0081003d                ee_vald_profil
                0x0081003e                ee_profilnamn
                0x008100b6                ee_profiler
                ... etc.

ee_hardware saknas i listan!

och jag hittar den inte alls i map-filen....

Det visar sig att jag råkat skriva i fel ordning:

Kod: Markera allt

struct EEMEM hw_setup ee_hardware = { 0 };

skall vara:

Kod: Markera allt

struct hw_setup EEMEM ee_hardware = { 0 };

Konstigt att ingen varning eller något liknande uppstod!
När jag kör simulatorn hittar jag den i SRAM på adress 0x0136.

I verkligheten (processorn) hade den hamnat i eeprom på adress 0x136.
Det fungerar alltså som tänkt - data lagras i eeprom och jag kan återkalla det när jag startar om på nytt.
Men detta är mycket förrädiskt! Tänk om något annat hade legat på just den adressen i eeprom?
Då hade de skrivit över varandra och mycket märkliga fel hade kunnat uppstå!

[labmaster]

Sitter applikationen i ett kärnkraftverk eller på annan kritisk plats?

[ronnylov]

Den där EEMEM är det ett macro som expanderas eller någon konstant från någon .h fil? Det kanske rent syntaxmässigt för programmeringsspråket C inte skett något fel som kompilatorn tycker sig behöva klaga på när den puttat dit det som EEMEM står för. Ja detta visar väl att C kan vara förrädiskt och att man lätt kan göra fel som kompilatorn inte upptäcker även om man kan tycka att den borde ha klagat. Inte för jag vet om det hade varit lättare med något annat programmeringsspråk heller för den delen.

Andra luriga grejer kan ju vara det här med kompilatorns optimering av kod. Viss kod som kompilatorn anser vara onödig då den till synes inte fyller någon funktion kan kompilatorn strunta i (det är väl typ sådana där saker som att försöka lägga in tidsfördröjningar med for loopar som inte gör något). Detta är väl bra för det mesta då den gör det snabbare men det tål att tänkas på när man felsöker.

Skönt att du hittade felet i alla fall!

[jesse]

Sitter applikationen i ett kärnkraftverk eller på annan kritisk plats?

Ja.
Felaktiga parametrar kan leda till explosion och brand med mera.

[ronnylov]

Tråkigt att få skulden för något sådant...

Å andra sidan har jag gjort typgodkännandeprovning för elsäkerhet. Ibland tänker man på vilka konsekvenser det skulle kunna få om man missat något som i förlängningen orsakar en brand eller att någon dör. Men man kan inte gå omkring och tänka på sådant hela tiden. Man kan ju se det tvärtom, man kanske har räddat livet på folk genom att underkänna farliga produkter. Du kanske just räddade livet på någon genom att fixa ditt program!

[jesse]

Det finns ganska mycket säkerhetsanordningar runt om, och även i mjukvaran, så om det blir fel kommer det antagligen att komma en massa felmeddeladen och eventuella processer stoppas. Men varje del får ju för den sakens skull inte vara opålitlig.