Stackkontroll PIC16
Re: Stackkontroll PIC16
Felet var ett stack overflow. Efter ytterligare en genomgång av "anropsträdet" så insåg jag att jag missat en tabellreferens. På små PIC:ar görs ju tabellreferenser till koden med "retlw"-instruktioner. Detta blir ju naturligtvis en extra nivå på stacken. På ett ställe hade jag missat det. Och det stället låg dessutom under avbrott, vilket hamnar "ovanpå" allting annat. Egentligen gör avbrottsrutinen en nivå subrutinanrop, alltså avbrotsnivån plus en nivå till. Men eftersom en tabell användes på ett ställe så blev det yterligare en nivå. Den tabellnivån är nu bortbyggd.
Re: Stackkontroll PIC16
Aha, va bra att du hittade det ! 
> På små PIC:ar görs ju tabellreferenser till koden med "retlw"-instruktioner.
Jag minns inte vilken modell du kör (eller vad du menar med "små"), men nyarne
modeller som t.ex PIC16F690 (20-pinnar) kan läsa Flash direkt (med i princip
samma metod som EEPROM) utan RETLW. Så det har mer med "gammal/ny"
än med "liten/stor" att göra.
> På små PIC:ar görs ju tabellreferenser till koden med "retlw"-instruktioner.
Jag minns inte vilken modell du kör (eller vad du menar med "små"), men nyarne
modeller som t.ex PIC16F690 (20-pinnar) kan läsa Flash direkt (med i princip
samma metod som EEPROM) utan RETLW. Så det har mer med "gammal/ny"
än med "liten/stor" att göra.
Re: Stackkontroll PIC16
Halvt on-topic, men som av en händelse så satt jag i förrgår och kliade mig i skallen några timmar på grund av ett väldigt märkligt fel. Har ett litet projekt som jag filat på ett tag nu som helt plötsligt utan förvarning började stanna slumpmässigt kort efter att jag startat upp det. Kunde inte för mitt liv förstå varför och höll på och skalade bort kod jag lagt till under kvällen för att spåra felet.
Inget hjälpte förrän jag slog igång Stack Overflow Reset och märkte att PICen startade om... Ytterligare nån timme rotande i koden, tillbakastegande till tidigare kod som jag visste fungerande osv, utan framgång. Sen, sent på kvällen så fick jag syn på en liten sladd som stack fram... visade sig att min provisoriskt ditlödda sladd för UART RX (som jag inte använder just nu men som är confad för att vara igång) hade gått av och orsakade ett stack overflow
Kände bara för att skriva av mig och kanske kan skadeglädjen göra någon glad
Inget hjälpte förrän jag slog igång Stack Overflow Reset och märkte att PICen startade om... Ytterligare nån timme rotande i koden, tillbakastegande till tidigare kod som jag visste fungerande osv, utan framgång. Sen, sent på kvällen så fick jag syn på en liten sladd som stack fram... visade sig att min provisoriskt ditlödda sladd för UART RX (som jag inte använder just nu men som är confad för att vara igång) hade gått av och orsakade ett stack overflow
Kände bara för att skriva av mig och kanske kan skadeglädjen göra någon glad
Re: Stackkontroll PIC16
Jag minns inte vilken modell du kör (eller vad du menar med "små"), men nyarne
modeller som t.ex PIC16F690 (20-pinnar) kan läsa Flash direkt (med i princip
samma metod som EEPROM) utan RETLW. Så det har mer med "gammal/ny"
än med "liten/stor" att göra.
Hehe. Det är inte så konstigt eftersom jag inte skrev det. Koden skall gå på det mesta i PIC16-väg. Just denna som jag debuggar just nu går på F877. Den koden som felade ligger i kommunikationsrutiner som ligger i alla "targets" och skall gå på allt från F628 till F877.
877 har väl den tabellslagningen, om jag inte minns fel. Visst kunde man använt den i just denna target, men då hade det blivit olika kommunikationsrutiner i olika targets och därmed ett underhållsproblem med specialkod för vissa targets. Bättre om det kan lösas på ett generellt sätt.
Bra att du hittade det, sånt kan vara (är!) en bitch att hitta!
Absolut
modeller som t.ex PIC16F690 (20-pinnar) kan läsa Flash direkt (med i princip
samma metod som EEPROM) utan RETLW. Så det har mer med "gammal/ny"
än med "liten/stor" att göra.
Hehe. Det är inte så konstigt eftersom jag inte skrev det. Koden skall gå på det mesta i PIC16-väg. Just denna som jag debuggar just nu går på F877. Den koden som felade ligger i kommunikationsrutiner som ligger i alla "targets" och skall gå på allt från F628 till F877.
877 har väl den tabellslagningen, om jag inte minns fel. Visst kunde man använt den i just denna target, men då hade det blivit olika kommunikationsrutiner i olika targets och därmed ett underhållsproblem med specialkod för vissa targets. Bättre om det kan lösas på ett generellt sätt.
Bra att du hittade det, sånt kan vara (är!) en bitch att hitta!
Absolut
