Tokig bugg i bootloader!!! (ATMega644)

[snigelen]

> Och, alltså, detta hindrar ju även att applikationen (helt oberoende av bootloaders)
> har egen data och tabeller i flash som man kanske skulle vilja uppdatera ibland.

Jo så är det. Inte för att det hjälper Jesse i detta läge, men lite nödlösningar finns ju:

Om man inte använder bootloader: Se till att den funktion som ändrar i flash hamnar i bootloader sektionen. Anropa den från application section (det går).

Om man använder bootloader blir det lite kluddigare.

Edit: AndLi sade ju just det. Missade det.

[jesse]

Det där med ett kommand-line-script som man kör mot en AVR-ISP skulle kanske vara lösningen. Så får man skicka runt programmeraren.

Ännu smidigare skulle vara om man hade allt på ett kretskort (programmerare, 64k hex-kod med både bootloader+applikation och kontroll/uppdatering av lockbits. Man bara ansluter till AVR-ISP-kontakten , väntar 2 sekunder, sedan uppdateras allt automatiskt. Efter kanske 10 sekunder så är allt klart och man hör ett pip / röd LED slocknar. Kan det bli mer användarvänligt? Ingen PC behövs.

[jesse]

Se till att den funktion som ändrar i flash hamnar i bootloader sektionen. Anropa den från application section (det går).

hmmm... bootloadern innehåller ju just instruktioner om att flasha i applikationen. Om jag kan lösa detta på ett smart sätt: Jag analyserar den befintliga bootloadern och ser om jag kan 'ful-hoppa' rakt till SPM-instruktionen där och hoppas att man med hjälp av att sätta lite register rätt kan programmera om de felaktiga bytena i bootloadern.

Alltså:applikation sätter data och adress och anropar sedan funktion i bootloadern...

[snigelen]

Men problemet är ju att bootloadern kommer att behöva skriva över sig själv. Så man skulle först behöva anropa denna SPM-rutin för att lägga till en kopia av sig själv i slutet av flash och sedan anropa kopian för att skriva in den nya bootloadern som förhoppningsvis får plats före kopian, så att den inte skrivs över sig sälv innan den skrivit den nya bootloadern färdigt. Det verkar rörigt.

[H.O]

Finns det ingen programmerare med Programmer To Go-funktionallitet till AVR? Det hade nog varit smidigast för både dig och dina kunder.

[jesse]

HO: exakt en sådan tänkte jag kunde vara bra.

This is a historical day for the PICKit2 programmer.
It is now possible to program AVR microcontrollers with PICKit2 without hardware/firmware modifications.

Programming Atmel AVR microcontrollers with PICKit2 programmer


snigelen:
Jag hade ju hoppats på att det skulle vara enklare. (Håller just nu på att studera SPM-instruktionen i databladet - komplicerat värre!)

Men jag hade inte tänkt ladda dit flera olika bootloaders. Det är bara en byte som behöver programmeras i bootloadern för att modden ska bli bra. En byte på adressen 0xfe53 = 0x7c ska ändras till 0xf8. tyvärr innebär väl det även en erase-instruktion, då bitar måste ett-ställas. Eventuellt kan man annars byta en hopp-instruktion mot en nop.

Funderar bara på om man verkligen bara kan ändra i en byte? Erase och programmering görs väl i pages?

Å andra sidan ligger bootloadern i ett område som heter NRWW - 'No read while write' - vilket bara betyder att processorns stannar (gör 'halt') tills skriv-instruktionen är klar. Sedan fortsätter den att köra koden där den var. Jag får läsa vidare...

[jesse]

Nej, det verkar inte fungera att uppdatera bootloadern 'inifrån'. Problemet är att SPM bara gör 'page erase' och page write' - det existerar alltså inget 'byte erase' eller 'byte write'.... Och eftersom operationen måste utföras i två steg - först erase och sedan write , så är det omöjligt - när man väl utfört 'page erase' på bootloadern så finns där ju inget mer... och ingen SPM-instruktion att anropa för att göra 'page write'... dead end.

Så nu lutar det åt en portabel uppdaterare. Hur jag nu ska lyckas bygga en sådan (pust! ska nog ta en paus nu! )

[Wise]

Orkar du inte bygga så finns det att köpa "keyfob's" här : http://www.kanda.com/ . Använder en del sånna i jobbet och de fungerar rätt så bra. Har iaf i runda slängar 10-12000 enheter programmerade med "fältvarianten" som inte är produktionsanpassad. Har hänt två gånger att programmerarna fallerat dock, men fungerar ändå bra i förhållande till mängden cycler.

[jesse]

Gjorde ett enkelt script (run.bat) för stk500 och satte ihop två hexfiler till en: dels bootloadern, dels applikationen.
Tror inte jag behöver göra en 'handheld programmer' då man ändå måste ansluta en PC senare för att uppdatera vissa parametrar.

Kod: Markera allt

@echo
@echo UPPDATERING AV BMS PROCESSOR BOOTLOADER VER 6.01
@echo
stk500.exe -s -datmega644 -y -e -pf -ifboot.hex -vf
pause

och så lade jag den tillsammans med stk500-filerna i en mapp. Sen var det bara att ansluta programmeraren och klicka på run.bat. Jag har en USB-ansluten AVR ISP* som jag får skicka med. Alla har ju inte serieport på sina datorer.

* note: alltså inte AVR ISP Mk II utan en AVR ISP med inbyggt FDTI-chip. Så i värsta fall måste en fdti-driver installeras också.