Att det sker page-vis är ju en sak, hurvida det går över huvudtaget
är ju en helt annan. Och att det *finns* EEPROM hjälper inte heller
om det inte räcker till. Att kunna lagra applikationsdata i flash
är praktiskt och bekvämt.
Tokig bugg i bootloader!!! (ATMega644)
Re: Tokig bugg i bootloader!!! (ATMega644)
Med lock-bits kan man som sagt avgör var LPM skall kunna läsa och var SPM skall kunna skriva (dvs läsa resp. skriva från/till application section eller bootloader section).
LPM kan finnas var som helst i flash och läsa var som helst ifrån (om man inte förhindrat det med lock bits).
SPM kan BARA (endast, enbart) köras från bootloader-sektionen om en sådan finns. Detta är omöjligt att ändra på. Man kan sedan begränsa var den skall få skriva med lock-bits, t.ex att den inte skall få skriva till bootloader sektionen.
Men rätta mig gärna om jag har fel.
LPM kan finnas var som helst i flash och läsa var som helst ifrån (om man inte förhindrat det med lock bits).
SPM kan BARA (endast, enbart) köras från bootloader-sektionen om en sådan finns. Detta är omöjligt att ändra på. Man kan sedan begränsa var den skall få skriva med lock-bits, t.ex att den inte skall få skriva till bootloader sektionen.
Men rätta mig gärna om jag har fel.
Re: Tokig bugg i bootloader!!! (ATMega644)
Nejdå, du verkar ha helt rätt. Det är just det som är problemet. 
Re: Tokig bugg i bootloader!!! (ATMega644)
Det var mest ett förtydligande angående
> En bootloader skall alltså uppdateras från applikationsområdet. Vilket kan vara fullt
> möjligt beroende på hur fuses är satta.
Det finns alltså, enligt vad jag sett/förstått, inte några fuses som gör att SPM går att exekvera från application section.
Men jag tycker nog inte det är något problem. Det finns ju som sagt EEPROM för "ganska konstant" data. Hade inte det funnits så hade det ju varit betydligt mer begränsande. T.ex STM32 brukar inte ha EEPROM, men där kan man ju lite enklare skriva till flash.
> En bootloader skall alltså uppdateras från applikationsområdet. Vilket kan vara fullt
> möjligt beroende på hur fuses är satta.
Det finns alltså, enligt vad jag sett/förstått, inte några fuses som gör att SPM går att exekvera från application section.
Men jag tycker nog inte det är något problem. Det finns ju som sagt EEPROM för "ganska konstant" data. Hade inte det funnits så hade det ju varit betydligt mer begränsande. T.ex STM32 brukar inte ha EEPROM, men där kan man ju lite enklare skriva till flash.
Re: Tokig bugg i bootloader!!! (ATMega644)
Ett problem är det ju faktisk! Iaf. för Jesse.
Med detta fel kan bootloadern inte uppgraderas per automatik men någon måste handha enheten manuellt och med enheter spridd rejält geografisk är det ett problem som heter duga.
Med detta fel kan bootloadern inte uppgraderas per automatik men någon måste handha enheten manuellt och med enheter spridd rejält geografisk är det ett problem som heter duga.
Re: Tokig bugg i bootloader!!! (ATMega644)
Visst går det att skriva med SPM från applikations området beroende på vilka fuse som är satt, enligt ATmega644 på sidan 273.
Så vilken lösning det blir beror på vilka fuse som är satta.
Om det är fel satt kan den enda lösningen vara att programmera om dem med ISP.
Så vilken lösning det blir beror på vilka fuse som är satta.
Om det är fel satt kan den enda lösningen vara att programmera om dem med ISP.
Re: Tokig bugg i bootloader!!! (ATMega644)
Nej det står det inte. Det står "No restrictions for SPM or (E)LPM accessing the Application
section."
Men nu har vi väl spammat tillräckligt men SPM (ha nästan SPAM) i den här tråden. Om någon känner för att diskutera det mer så tycker jag att det är lämpligare att starta en ny tråd.
Så till ursprungsfrågan. Jag ser ingen annan (enkel) lösning än att skicka runt en ISP-programmerare med instruktioner om hur flashningen skall gå till.
Man kunde kanske modda en existerande ISP-applikation för att programmera just rätt bootloader automatiskt för att göra proceduren något enklare för kunden. Men det känns lite overkill, såvida man inte råkar hitta en färdig sådan lösning.
section."
Men nu har vi väl spammat tillräckligt men SPM (ha nästan SPAM
) i den här tråden. Om någon känner för att diskutera det mer så tycker jag att det är lämpligare att starta en ny tråd.Så till ursprungsfrågan. Jag ser ingen annan (enkel) lösning än att skicka runt en ISP-programmerare med instruktioner om hur flashningen skall gå till.
Man kunde kanske modda en existerande ISP-applikation för att programmera just rätt bootloader automatiskt för att göra proceduren något enklare för kunden. Men det känns lite overkill, såvida man inte råkar hitta en färdig sådan lösning.
Re: Tokig bugg i bootloader!!! (ATMega644)
"Alla" atmels programmerare går utmärkt att styra via ett command line tool. Bara att göra göra ett batscript som fixar inställningarna...
Re: Tokig bugg i bootloader!!! (ATMega644)
Hejsan allihopa. Har inte haft tid att vara inne här på ett tag...
Det är precis så som ni redan konstaterat, att om man ska kunna skriva alls i flashminnet måste vissa lockbits vara 'rätt'. Oprogrammerade lockbits ger de största möjligheterna till ändring.
Databladet, atmega644P, sidan 10:
En tolkningsfråga: Om nu SPM-instruktionen som skriver i applikations-ytan måste ligga i bootsektorn, finns det då inga begränsningar var SPM-instruktionen ska ligga om den ska skriva i boot-sektorn? Det står det ju ingenting om. Annars kan man ju låta en applikation skriva i Bootsektorn och på så vis rätta till felet. Det kan ju vara lite vanskligt att göra på distans - minsta fel och bootloadern är körd och inget kommer att fungera förrän man skaffat en programmerare. Annars kan man ju tänka sig att:
Kunden får en "fix" i form av applikation som laddas ner av bootloadern. Fixen rättar till felet i bootloadern. Sedan uppgraderar kunden med senaste versionen av applikationen med hjälp av den reparerade bootloadern. Detta går givetvis att testa. Jag får experimentera lite.
Jag kan inte se att det skulle vara omöjligt att skriva i boot-sektorn från applikationen, förutsatt att lockbitsen är oprogrammerade: Det handlar om ett fåtal kretskort, kanske 10 st, som vart och ett kan vara speciellt anpassat, så de är inte rakt av utbytbara. Kunderna vill nog inte vara utan dem mer än några timmar, misstänker jag. (Absolut inte flera dagar). Flera av dem har nog så pass bra erfarenhet att de skulle kunna lägga in en ny bootloader själva om de bara får låna en programmerare och får instruktioner, men kanske inte alla.
Ett problem kan vara att det kan vara trångt att få dit programmeringskontakten. Men sådant går ju att lösa.
Det är precis så som ni redan konstaterat, att om man ska kunna skriva alls i flashminnet måste vissa lockbits vara 'rätt'. Oprogrammerade lockbits ger de största möjligheterna till ändring.
Databladet, atmega644P, sidan 10:
Enheterna bör inte ha några lock-bits satta. Jag har lämnat dessa orörda, eftersom jag inte var 100% säker på hur de påverkade. Egentligen borde jag ha skyddat boot-sektorn, men det kanske var bra att jag inte gjorde det.Program Flash memory space is divided in two sections, the Boot Program section and the
Application Program section. Both sections have dedicated Lock bits for write and read/write
protection. The SPM instruction that writes into the Application Flash memory section must
reside in the Boot Program section.
En tolkningsfråga: Om nu SPM-instruktionen som skriver i applikations-ytan måste ligga i bootsektorn, finns det då inga begränsningar var SPM-instruktionen ska ligga om den ska skriva i boot-sektorn? Det står det ju ingenting om. Annars kan man ju låta en applikation skriva i Bootsektorn och på så vis rätta till felet. Det kan ju vara lite vanskligt att göra på distans - minsta fel och bootloadern är körd och inget kommer att fungera förrän man skaffat en programmerare. Annars kan man ju tänka sig att:
Kunden får en "fix" i form av applikation som laddas ner av bootloadern. Fixen rättar till felet i bootloadern. Sedan uppgraderar kunden med senaste versionen av applikationen med hjälp av den reparerade bootloadern. Detta går givetvis att testa. Jag får experimentera lite.
Jag kan inte se att det skulle vara omöjligt att skriva i boot-sektorn från applikationen, förutsatt att lockbitsen är oprogrammerade: Det handlar om ett fåtal kretskort, kanske 10 st, som vart och ett kan vara speciellt anpassat, så de är inte rakt av utbytbara. Kunderna vill nog inte vara utan dem mer än några timmar, misstänker jag. (Absolut inte flera dagar). Flera av dem har nog så pass bra erfarenhet att de skulle kunna lägga in en ny bootloader själva om de bara får låna en programmerare och får instruktioner, men kanske inte alla.
Ett problem kan vara att det kan vara trångt att få dit programmeringskontakten. Men sådant går ju att lösa.
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Re: Tokig bugg i bootloader!!! (ATMega644)
Nästa steg blir att:
1) skriva en applikation som läser av bootsektorn och kollar att det är rätt version av bootloader.
2) ersätta 0x7c00 med 0xf800 på rätt ställe med hjälp av SPM i applikationen.
3) testa om den 'nya' bootloadern fungerar / göra en hexdump på flashminnet för att verifiera ändringen.
1) skriva en applikation som läser av bootsektorn och kollar att det är rätt version av bootloader.
2) ersätta 0x7c00 med 0xf800 på rätt ställe med hjälp av SPM i applikationen.
3) testa om den 'nya' bootloadern fungerar / göra en hexdump på flashminnet för att verifiera ändringen.
Re: Tokig bugg i bootloader!!! (ATMega644)
26.3.1 i doc8272.pdf:
The Application section is the section of the Flash that is used for storing the application code.
The protection level for the Application section can be selected by the application Boot Lock bits
(Boot Lock bits 0), see Table 26-2 on page 283. The Application section can never store any
Boot Loader code since the SPM instruction is disabled when executed from the Application
section.
Re: Tokig bugg i bootloader!!! (ATMega644)
Allt talar för att du *inte* kan "modda" bootloadern från applikationskod.
Re: Tokig bugg i bootloader!!! (ATMega644)
skit också 
tack för hjälpen.
får tänka vidare.
Bootloadern skulle alltså kunna skriva över sig själv, men det kan den inte eftersom den har ett mjukvaruskydd mot det... moment 22.
tack för hjälpen.
får tänka vidare.
Bootloadern skulle alltså kunna skriva över sig själv, men det kan den inte eftersom den har ett mjukvaruskydd mot det... moment 22.
Re: Tokig bugg i bootloader!!! (ATMega644)
Ja, den kan det om man inte har satt skrivskydd på boot-sektorn och om
koden som skriver körs i boot-sektor.
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.
koden som skriver körs i boot-sektor.
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.
Re: Tokig bugg i bootloader!!! (ATMega644)
sodjan: vi har förstått att du tycker det är ett problem nu, ska vi gissa att PIC inte har denna begränsning?? 
Vill man nu ha en tabell som går att ändra i flash (som bara är garanterat för 10 000 uppdateringar) så får man väll helt enkelt ha en funktion i bootloader sektionen som kan uppdatera tabellen åt en. Anropa den med en pekare till ramminnet man vill stoppa in i flashet, done.
Vill man nu ha en tabell som går att ändra i flash (som bara är garanterat för 10 000 uppdateringar) så får man väll helt enkelt ha en funktion i bootloader sektionen som kan uppdatera tabellen åt en. Anropa den med en pekare till ramminnet man vill stoppa in i flashet, done.
