Svenska ElektronikForumet

Jag tycker mig se ett visst behov av att berätta hur man kan debugga i en µC utan så mycket utrustning.

Jag brukar se till att ha 1 eller 2 pinnar i reserv med testpunkter på ett kretskort, dessa använder jag till debuggning.

Nu kommer problemet: HUR ska man använda dom?

Svaret är att det beror på vad man har av utrustning. Man kan komma långt med en simpel LED då problemet ofta är "händer det att den kommer hit i programmet?" och då kan man nolla LED-pinnen vid programstart och peta in en instruktion som slår på LED'n när den kommer dit man vill veta.

Tänds den... då kom programmet dit.

Om man tror att den fastnar i en loop: slå på vid loop-starten och av vid loop-slut, blinkar den till lite då och då, går den in och ur men lyser den kontinuerligt "fullt" har den fastnat.

Detta kan man göra med 2 LED till att testa olika delar, i min erfarenhet kan man komma mycket långt på det vis.

Finns det en UART i kretsen? Kanon! Då kan man ställa rätt den och har en MAX232 liggande som är färdigkopplat, bara att plugga in +5V, GND samt seriesignalen.

Starta ett terminalprogram och lämpliga ställen i programmet som man vill "markera" begär man med en liten kodsnutt att den ska vänta på att UART'en kan sända (ifall något annat är på väg ut) och sedan skickar man ett tecken ('A', 'B'...) som ett tecken på att programmet passerade.

Detta stjäl minimalt med hastighet om man ser till att skriva ut så lite som möjligt.

Om man då har ett oscilloskop är det än bättre: Löd fast ett litet ögla på ett eller fler testpunkter, då kan man se dels i vilken sekvens som saker händer och dels vilka saker som sker:
Punkt #1: skicka en '1' och sedan en '0'
Punkt #2: skicka en '1' och sedan en '0', sedan en '1' och sist en '0'
osv.
Ha inte gärna mer än 5 pulser då det kan bli svårt att se direkt hur många pulser det finns, 5 är det värde man kan se med ett snabbt titt.

På det vis kan man se vilket punkt som programmet är på. Jag brukar använda det ena testpunkt till att markera start på main-loop (som man ju oftast har) och det andra till att markera de olika delar.

När man sedan har fått systemet att komma igång kan man utöka serieporten, om en beräkning blir fel kan man tvinga utförandet av beräkning och skriva ut alla mellanresultat i klartext på serieporten, på det vis kan man fånga många fel och konstigheter.

Om man har problem med att fler saker går fel eller att man misstänka att det är så kan det löna sig att kommentera bort kod som inte är essentiell. Det kan t.ex. röra sig om en timer-interrupt som kan haka upp sig.

Kommentera då bort det som inte är essentiellt för interruptdelen och tänd och släck en testpinne, om den växlar händer interrupten, om den lyser fullt eller är svart kontinuerligt sker det inte eller den har hängt sig.

Man kan även mäta spänningen på dessa testpunkter om det är snabba signaler, om vi utgår ifrån ett 5V system betyder en mätt DC-spänning på 2,5V att pinnen har en dutycycle på ca: 50%.

Så man kan komma långt med en LED, har man ett multimeter kan man kolla lite mer och med ett oscilloskop är det kanon.

Visst kan man använda en LSA (Logic State Analyzer, logikanalysator) men min erfarenhet är att det sällan är så allvarliga problem att det är aktuellt.

Det här borde alla som pysslar med mikroprocessorer läsa tidigt i sin karriär för det är riktigt bra tips! Designar man från början så man kan debugga så här så blir det väldigt enkelt.

Helt klart en konst att lära ut och skriva mer om!

Är själv en nästan fanatisk användare av de tips Icecap ger, iof nästan alltid med ett oscilloskop anslutet...

I min ungdom även med lysdioder, ögat är väldigt snabbt på att se förändringar i en signal. Ett hack i en annars jämn puls av blink är lätt att se..

uart debugging (aka printf debugging (vilket iof drar en väldans massa mer resurser, men det är väll sällan man faktistk använder printf för denna typ av debugging)) är med smart genomtänkta placeringar av utskrifterna väldigt hjälpsamt. Men man vill ju inte få för många utskrifter heller, en konst att hitta en balans.

Måste säga att det är sällan jag hamnar i några projekt där det finns några ambitioner att använda emulatorer och dylikt. Visst saknar man de ibland, men tycker oftast det är en massa bök med att breakpoints inte alltid löser, variablerna uppdateras inte. Sen ska man ju få det att snurra i sin målmiljö med... Fast senaste hobbyprojektet med de där korten renesas dela ut gratis användes ju faktistk deras debugger och den funka

Men endå, mer printf debugging åt världen:) (Undra hur många kunder jag skrämde bort med det uttalandet... Lovar ska genast gå och kompilera gdb för AT91an..)

Om man ska USART-debugga från C så är deet nog bättre att skriva
en liten egen snabb USART-rutin så slipper man länka in hela printf
(om man inte behöver det till annat i alla fall, vill säga).

Jag håller med om att det beskrivna sättet fungerar mycket bra, antagligen bättre än emulatorer och ICD i många fall eftersom det är så minimal overhead.

Har projektet en display av någon form så är denna givetvis ett jättebra hjälpmedel för att debugga. Då behöver man sällan göra några extraarrangemang alls.

Man kan också lägga in stoppunkter, där den stannar och väntar på en yttre händelse typ tryckknap för att lättare kunna debugga då inte allt händer på en gång.

Sist men inte minst, små steg i taget. Inte försöka få ett helt program att fungerapå en gång. Dela upp problemet i mindre delar och få varje del att fungera separat.

Gör dem som en subrutin om det inte är takkänning i stacken. Det hjälper till att få ett snyggt och prydligt program där man lätt kan återanvända delar och får lättare att serva det längre fram.

2 pinnar då funkar DebugWire(1 pinne) på avr, ICD2 på microchip, SWD på cortex-m3. Jag föredrar att ha en debugger så man inte behöver ladda om programvaran varje gång man vill göra förändringar.

uart debug funkar ok, men är inte lika snabb att hitta fel som en debugger.

Så fort man har lusat av koden mot hårdvaran så brukar jag simulera och fejka inputs till högre lager om det behövs. Mycket smidigare att testa logiken utanför hårdvaran.

Edit: Har man problem med stacken så kan man alltid deklarera funktioner inline, då tjänar man struturellt samtidigt som koden borde bli samma som när allt är ihopslaget.

Bra Icecap!

Jag har länge tänkt skriva något liknande men det har blivit liggande. Jag har ungefär samma erfarenheter. Till vissa saker är en emulator/debugger väldigt bra och till andra saker är dessa enkla saker bättre. Till många problem funkar båda metoderna och man använder det som man har tillgängligt!

Din text borde med i antingen FAQ eller Wiki på hur man kan felsöka, kanske kompletterat med lite ytterligare info. Då skulle nog många här kunna hitta sina fel själva. Det är ju inte så att vi inte hjälper till när det behövs, men det ger alltid en go tillfredsställelse att ha löst ett problem själv. Plus att man blir mer erfaren efterhand.

In i wikin

Har en liten rutin i Int-Rutinen, som exekveras om jag trycker på en knapp (HW-Int), Skickar iväg PIC'ens PC + HW stack på serieporten, använder det när jag har en "runaway".

Har ni nått bra tips på hur man debuggar t.ex en display eller någon form av mer avancerad sensor som behöver ett initieringsförfarande?
t.ex så är det en hel del displayer som behöver kommunicera med t.ex spi, paralellport, eller eeprom via i2c. Då kan det både vara problem med protokollet, initieringsförfarandet och även timingen.

Själv brukar jag försöka verifiera protokollet genom att verifiera hårdvaran, titta på hur pinnarna ändrar state och jämföra med databladet.

Därefter verifierar jag timinen och försöker köra hyfsat långsam hastighet på dataöverföringen.

sisst försöker jag köra mina initieringsförfaranden och försöka se om man får något svar från enheten man pratar med i from av t.ex titta på pinnar ut, om strömförbrukningen ändras osv när man försöker initiera.

Det jag tycker är lurigt är enheter (som t.ex en display som jag hade problem med) då man kör paralellt in och får inget som helt gensvar på om den överhuvudtaget tar emot kommandona eller om man skickar kommandon i fel ordning osv. Någon som har extra tips angående detta?

Oscilloscop och logikanalysator är det enda som kan hantera det, då timingen i regel är rätt kritisk på displayer, då kan man i regel inte singelsteppa programmet, dessutom så måste man ju veta vad som händer i riktig realtid.

Ett bra sätt att felsöka när man infört ett fel är jämförelser. Säg att man har en fungerande version men vill förenkla eller förbättra denna på något sätt. Efter förändringen så fungerar inte programmet likadant (kanske inte alls).

Det finns vettiga jämförelseprogram, t.ex 'Windiff' (fri) där man kan jämföra valfria texfiler med varandra. Jag har kört en del med Araxis Merge (komersiell produkt) och denna har dessutom funktionen att jämföra alla filer i en mapp. Från den vyn kan man sedan dubbelklicka på en fil som skiljer och öppna bara den filen i filjämföraren.

Genom att med dessa, eller liknande verktyg, jobba sig igenom alla skillnader som man infört så kan man så småningom komma fram till vilken skillnad som ställer till det. Det har räddat mig många ggr.

vfr: subversion är vettig då du sparar ner "fungerande versioner" och kan lätt jämföra dessa med aktuell version.

Sedan får man lite backup på köpet.

Micke_s skrev:vfr: subversion är vettig då du sparar ner "fungerande versioner" och kan lätt jämföra dessa med aktuell version.

Sedan får man lite backup på köpet.

Absolut!

Edit: Tänkte mest att det kanske kändes som ett väldigt stort steg att använda versionshantering för den som är nybörjare. Min variant gör egentligen i stort samma sak fast enklare att förstå och börja med.

Eftersom det talades lite om versionshantering vill jag passa på och rekommendera Mercurial som jag tycker är mycket bättre än subversion.