totalkrasch AVR

[jesse]

satans...

Nu är det fest, men jag är ändå lite sur. Satt hela natten i går kväll och programmerade , fortsatte på morgonen, och hade tänkt spara resultatet nån gång vid lunchtid för att resa till midsommarstången.

Men precis när jag var på väg att lägga ner, så laddade jag upp sista programversionen i processorn - och den spårar ur fullständigt. Och senaste backupen var sparad ca 12 programmeringstimmar tidigare - ett jävla jobb, med andra ord.

Jag hade INTE pillat på några kritiska delar... bara lite beräkningar som printas ut på UART... inget som skulle kunna få processorn att fastna. Men jag vet sen innan att det är lätt att "slinta med musen" och råka radera ett programstycke eller så. Normalt får man då lite kompileringsfel, men inte denna gången.

Det konstiga är att programmet fungerar som vanligt när jag kör i simulator.
Har testat en massa saker - t.ex. raderat hela processorn och laddat om bootloadern etc... men inget hjälper.

Den totala källkoden är på 35 kB och består av 19 filer....

Nu sitter jag med gamla versionen igen... fy fan så trött jag blir

Själva processorn funkar i alla all - det går utmärkt med den gamla versionen av programmet.

[bos]

Alltid trist med krasch, fast jag är inte riktigt med på vad det är som hänt. Du skulle skicka upp / in din senaste kompilering till processorn, den kraschar och med i fallet åker dina källkodsfiler? Eller vad är det för 12 timmar som försvunnit?

[ahlsten]

Hjälper det inte att kolla en diff mellan gamla och nya kodbasen?

[jesse]

Jag har utökar progrmmet med ett antal funktioner och beräkningar ... det är 12 timmars jobb... med kanske 20 minuters mellanrum laddar jag upp programmet till processorn för att köra i en realistisk miljö. Men plötsligt slutade hela programmet att fungera. Jag vet inte varför.

Visst har jag källkoden, men vad ska jag ha den till när den är oanvändbar?
Jag måste alltså antingen hitta felet eller börja om från början, och utgå från den källkod jag hade 12 timmar tidigare.

Har tyvärr inte någon stackdump eller liknande tillgängligt för tillfället. Kan ju varit något som slukat stacken, eller att jag gjort nåt galet med en pekare så jag skrivit över stacken eller annan vital data...? Men än har jag inte hittat ett spår.

hur kolla en diff?

som sagt, jag har lagt till massor av kod , så det är en massa diff... Men visst, då vet jag ju var jag ska läsa och inte läsa.

[sneaky]

Detta är anledningen till att jag alltid sparar kompletta versioner av min kod med jämna mellanrum (på en separat server dessutom). Brukar spara en kopia varje gång jag lagt till något nytt som fungerar. Ingen tröst, jag vet, men kan vara en idé för framtiden.

[jesse]

det konstiga är att i simulator så går det bra.... ingen tendens till att stacken växer eller att data skrivs över... men i hårdvara så går huvudloopen ett eller kanske två varv innan den tvärstannar.

hoppsan... har plötsligt identifierat processordöden med en enhet på SPI-bussen.... mycket märklgt. Det är alltså beroende av inkommande data. Mysteriet tätnar.

Hur ska jag få reda på var den befinner sig när den stannar?

[jesse]

Det är troligen en heltalsdivision som fastnar.

Jag bytte ut divisionsrutinerna för att effektivisera - jag hade kört de nya rutinerna i ett testprogram innan och tyckte att de fungerade, men jag missade visst någon detalj. De kan i vissa fall fastna vid division med negativa tal misstänker jag. Så nu blir det att rensa lite.

SPI-enheten som var ansluten gav negativa värden... när jag ändrade det till positiva (vrida på en pot) så funkade programmet igen. Tänk vad lätt det hade varit om jag haft en sån där panikknapp som spottar ur sig PC (program counter) med mera... men jag lyckades inte implementera den knappen nu. (A: jag lyckades inte få interrupten att fungera, B: jag vet inte hur jag ska få tag på adressen i PC - det är antaglien en massa pushande på stacken innan jag kommer vidare. Det går visserligen att kringgå det - och då hade jag fått göra en assemberkod där som letar upp värden på stack med mera....

tror snart detta får sin lösning.

[ahlsten]

Någon sorts On Chip Debug vore fint vid sådana tillfällen, ATMEL har nått som heter JTAGICE?

[jesse]

Jo, det hade varit fint.... just i denna applikationen hade det varit värre.. använder de flesta utgångarna, så JTAG:en hade inte fått plats.

Men nu har jag löst problemet...

skala ner 32-bitars värde i a till 16-bitars: hur man inte ska göra:
while( a & ~0x7fff ) { a >>= 1 } // inte bra om a är negativ!

Äntligen!
då var det dags att sova!

[sodjan]

Nu så är det ju tydligen löst, men i alla fall...

> ...med kanske 20 minuters mellanrum laddar jag upp programmet till processorn för
> att köra i en realistisk miljö. Men plötsligt slutade hela programmet att fungera.

Men då borde det ju vara "bara" 20 minuters jobb som behöver backas,
inte 12 timmar ? Versionen från 20 minuter tidigare måste väl ha fungerat,
annars hade det varit den som hade stannat.

[jesse]

Nej, varje gång jag kompilerar så sparas ju källkoden och då skrivs ju den äldre versionen över. Och senaste säkerhetskopian gjordes alltså dagen innan.
Att jag testar koden på processorn väldigt ofta gör ju inte att jag kan gå tillbaks i historiken.

Sen kan man tycka att det är klantigt att inte minnas vad det var jag ändrade i koden, då den pajade... Men så här var det: jag hade gjort ändringen - testkört i simulator - fortsatt programmera, testkört i processor osv... och allt hade fungerat... det var när en uppmätt ström från en enhet på SPI-bussen plötsligt bytte polaritet som det tvärstannade... det kanske var mer än en timme efter att jag skrivit den felaktiga koden, så jag associerade inte direkt till den. Och det var ju först i efterhand som jag kom på att det berodde på en negativ siffra - jag märkte nämligen att om jag drog ur SPI-kontakten helt från processorkortet så fungerade den om jag startade om processorn, nästa stg var att jag drog ur kontakterna till de olika SPI-enheterna en och en och startade om processorn - och när jag kom till min 150A strömsensor så funkade det plötsligt - då gick jag in i koden i filen ampere.c och kollade readCurrent()... och mycket riktigt - där hade jag varit och pillat på koden några timmar innan. Såg att den borde fastna om strömmen var negativ.. så jag vände på strömmen och - ja. det funkade igen.

Det är väl programmerarens dilemma, att försöka testa programmet i alla tänkbara situationer. Ofta är det inte ens möjligt att testa extrema värden t.ex. utan att kanske modifiera hårdvaran att simulera de extrema omständigheterna, alternativt att man i mjukvaran lägger in påhittade data för att kolla att det inte blir konstiga owerflow eller annat skumt. Men man är ju aldrig säker... den där oändliga loopen hade kanske uppstått i en mer sällsynt situation - i så fall ahde jag aldrig upptäckt den, utan den hade plötsligt en dag i skarpt läge fastnat, pga. att vissa data blivit på ett visst vis.

[blueint]

Isolera beräknings- och logikkod från I/O delarna. Så att du kan mata in färdiga scenarion som testar -max .. 0 +max osv. Gärna i olika omöjliga kombinationer. Då kan man snabbt testa koden effektivt.

[Icecap]

jesse: det är just det som är det svåraste: att säkerställa att koden fungerar i alla lägen! Själv räknar jag igenom alla extremfall och vid tveksamheter testar jag i praktiken med "falska" data och uträkningar som kan fastna i en loop ser jag till att undvika.

[AndLi]

Det är vid sånna här lägen man inser fördelarna med lämpligt versionshanteringssystem. Varje gång saker funkar checkar man in alltihop, man slipper trettielva kataloger med mystiska namn som man sen inte vågar radera för att man kanske behöver dem i framtiden.

Vissa av AVR:ena har ett debuginterface som i princip bara behöver resetpinnen... (men jag verkar ha drömt det hela för jag kan inte hitta några referenser till det. µC som var med från elfa i tävlingen i julas var jag rätt säker på hade den featurn)

[ds77]

debugwire tänkter du på, stds av dragon jtagicemkII med flera. Det är främst de mindre modellerna som har detta.