Tokig bugg i bootloader!!! (ATMega644)

[jesse]

Jag håller på (som vanligt) och skriver AVR-program för fullt, när plötsligt flera mycket knepiga fel uppstår... Jag har bara lagt till några rader kod - som dessutom bara ska köras i undantagsfall, men dessa extra rader gör ändå så att antingen programmet hänger sig vid uppstarten eller att LCD-displayen blir helt svart....

Efter fyra dagars felsökande och mycket tandagnisslan börjar det gå upp för mig: det måste vara något tok med bootloadern! Så jag körde ett jämförelseprogram på hexkoden dels genererad av AVR Studio 5, dels vad jag dumpade från AVR-processorns flashminne. Och plötsligt syns problemet tydligt:

bootloader_err.png

Jag använder en ATMega644. Den ska ha 64Kbyte flashminne (0x0000 - 0xffff). Bootloadern tar upp 2048 bytes i slutet, alltså från 0xf800-0xffff. Problemet är nu att Atmel brukar ange flash-adresser i word, inte bytes! Så en ATMega644 har 0x8000 words och bootloadern ligger på adress 0x7c00.

Vad bootloadern gör är att den tror att gränsen går vid 0x7c00 bytes, alltså bara halva utrymmet.

Så nu kan jag bara använda halva flashminnet, om jag inte kan lägga in nya bootloaders!

Bootloadern är köpt av en tysk firma, men jag tror inte jag ska skylla på honom. Det kan mycket väl vara jag som lagt in fel parametrar i koden.

Hur ska jag göra nu? Jag har mina ATMega644 på lite olika ställen i bl.a. Norrköping, Örebro, Södra Norge, Täby, Köpenhamn.... antagligen med programmeringskontakten (AVR-ISP) ganska svåråtkomlig. Det blir väl att jag får skicka runt en AVR-ISP-programmerare med en korrekt bootloader och hoppas att folk klarar av att följa instruktioner hur man lägger in en ny bootloader. Eller så får jag banta programmet på en del mindre viktiga funktioner.... Fast på sikt behöver jag ha mer flashminne än 0x7c00 bytes.

[thebolt]

En lösning är ju att flasha om bootloadern via en tvåstegsprocess. Det finns en liten risk att det går fel och inte funkar, men å andra sidan är ju lösnignen då att använda ISPn, så om 90% av fallen går bra så är det kanske ändå en besparing.

1a. Skriv ett litet program som har en ny bootloader som data i sig. När programmet startar så skriver den över bootloadern i flash. Använd den gamla bootloadern ("bootloader-flashern" bör vara liten nog för att klara det) för att ladda detta.
1b. Start om processorn och låt ditt "bootloader-flasher" köra, den skriver över bootloadern med en ny.
2. Använd den nya bootloadern för att ladda in ditt riktiga program.

[snigelen]

Instruktionen SPM, som behövs för att ett program som kör på AVR'en skall kunna skriva till flash, fungerar bara om den ligger i bootloader-sektionen av program-minnet.

[sodjan]

Gäller den begränsningen enbart skrivning till just den del av flash där bootloadern ligger?
Det måste ju finnas metoder för att skriva till flash rent gennerellt från user-code också.

[snigelen]

Nej det gäller hela flashminnet. Så det blir lite extra kludd om man av någon anledning skulle villa skriva flashminnet från ett vanligt program (dvs inte en bootloader). Men detta gäller inte tiny's (och mega48 har jag för mig), de har ingen bootloader-sektion så där kan SPM ligga var om helst. (utom 6-pinnars tinysar, som inte har SPM).

[sodjan]

OK, så det finns andra metoder att skriva till flash än genom SPM.
Ja, det verkar väl rimligt. Att skriva till flash är ju inte helt ovanligt eller
något konstigt. Config data eller tabeller som inte rymms i EEPROM t.ex.

[snigelen]

Jo man skriver ju normalt flash med typ ISP, men då är det ju en extern enhet som gör det och det exekveras inga instruktioner i MCU'n under tiden.

Så om ett program som exekveras på MCU'n skall skriva till flash så måste det ske genom SPM. Då får man helt enkelt se till att den delen av programmet som skall skriva till flash ligger i bootloader-sektionen.

[AndLi]

Nu vet jag inte hur korten ser ut, eller vad det är för enhet, eller hur många du installerat, men ett utbytesprogramm brukar väll vara enklare för "kunden". Du skickar en ny enhet till dem, du får hem deras "trasiga" enhet och fräshar upp den och testar den. De uppfräshade enheterne skickas till nästa kund som, skickar in sin enhet.
Problemt verkar ju inte vara akut för kunden, så med 3-4 extra kort kan man väll få bra snurr på loopen? Funkar ju nu bara om det inte är massa olika specialkort...

Risken med att kunden ska meka bootloader är ju alltid att du endå får tillbaka korten för att "reparera" dem..

[Andax]

Så man ska se till att det ligger en liten subrutin sist i bootloader sektionen som skriver ett word till godtycklig adress i flash som man sedan kan anropa från user-code?

[snigelen]

Ja. Nästan. Men det går inte att bara skriva ett word utan en page (32, 64 eller 128 words) åt gången. Så typ
- läs in en page
- modifera där det skall modifieras och fyll en page-buffer.
- radera "the page"
- skriv den nya

och så måste man fippla med bitar i SPMCSR och exekvera SPM inom fyra clock-cykler. Ungefär så i alla fall. (Otestat).

[sodjan]

> Jo man skriver ju normalt flash med typ ISP,

Ja, jo, men det är ju en helt annan sak.

> Så om ett program som exekveras på MCU'n skall skriva till flash så måste
> det ske genom SPM. Då får man helt enkelt se till att den delen av
> programmet som skall skriva till flash ligger i bootloader-sektionen.

De där låter ju världigt märkligt, men det verkar efter lite googling faktiskt vara så.
(ATmega48A är ett undantag, eftersom den saknar bootloader area så kan den
exekvera SPM från hela programminnet.)

Så man kan alltså inte ha egen kod där man kan ha t.ex en datatabell som uppdateras
dynamiskt via UART/USB eller liknande. D.v.s om inte koden som gör det ligger
inom bootloader-arean. Lite begränsande.

[Swech]

Det börjar bli lite mycket spekulationer och dyl i tråden...
Det finns några fuses som bestämmer vad och hur LPM SPM instruktionerna skall få fungera.

Så beroende på hur dessa bitar är satta så kan LPM /SPM vara tillåtet / blockerat
i applikation och eller boot loader arean.

Eftersom boot loadern är ett rent program och den ligger i en bootloader area så skulle det
gå åt h* om den satte igång att uppdatera sig själv medans den kör.
En bootloader skall alltså uppdateras från applikationsområdet. Vilket kan vara fullt möjligt
beroende på hur fuses är satta.
Det är inte någon begränsning utan det är för att hålla systemet säkert.

Så har man en bootloader som är 100% ok, så kan man skydda denna. Så även om det skulle
skita sig under en uppdatering så överlever bootloadern. Priset är att bootloadern inte går
att modifiera.
Annars kan man köra oskyddat. Bootloadern går att uppdatera. Priset är att om en bootloader uppdatering skiter sig så kan systemet gå ned sig och kräva en ISP omprogrammering.

För övrigt om man behöver parametrar som skall kunna ändras externt så lägger man
dessa i det interna eeprom minnet. Inte i programflashen. Detta minne är tillgängligt
byte för byte och inte i block om 256 bytes....

Swech

Swech

[sodjan]

Ja, det var inte specifikt för en bootloader jag underade, utan mer
generellt om man behöver lagra applikationsdata som kan behöva
ändras "live".

EEPROM så klart, men det är normalt "bara" 256 bytes.

Men kan man via fuses ställa om så att SPM fungerar oavsett
var det körs ifrån i preogramminnet, så är det ju redan "löst".

[thepirateboy]

> EEPROM så klart, men det är normalt "bara" 256 bytes.

Nej, Atmega har mellan 256-4096 bytes eeprom beroende på modell.

[snigelen]

> Det börjar bli lite mycket spekulationer och dyl i tråden...

Det kan hända. Men nu blev det fler...

> Det finns några fuses som bestämmer vad och hur LPM SPM instruktionerna skall få fungera.

Det finns inga fuses (dvs lfuse, hfuse eller efuse) som styr detta. Men det finns Boot Lock bits som gör det (man skulle väl kunna kalla dem fuses också, men då går man utanför nomenklaturen i databladen).

Och flash är naturligtvis tillgängligt för läsning byte för byte via LPM, det är bara radering och skrivning som måste ske page-vis.