ATmega644: bootloader?

[jesse]

Är det någon som testat att använda bootloader på någon ATmega-processor? Skulle vilja installera en sådan på en ATMega644 men tycker det verkar krångligt. Finns visst en massa bootloaders att ladda ner på nätet med skiftande kvalitet... Att göra själva bootloadern är inte huvudproblemet, jag kan säkert fixa något som kan ta emot data på ett bra vis (måste även programmera EEPROMet samtidigt) men det är just konfigureringen som jag tycker verkar knepigt:

själva programmet (applikationen) som ska laddas in i processorn: som jag förstår det så börjar alltid programmet på adress 0000 även om det finns en bootloader, så det behöver med andra ord inte modifieras?

Hur kommunicerar jag med bootloadern från en PC? Vilka program går att använda som är smidiga? jag tänker inte "bootloada" från AVRStudio - jag vill ha ett enklare program som bara läser in hexfilerna.

nån som gjort det här innan får gärna tipsa om hur, och vilken bootloader och program som användes!

EDIT: har tagit bort ett par frågor som jag fått svar på redan.

[Johanb]

Om jag kommer ihåg rätt så lägger man bootloadern i slutet på flashminnet och talar om med fusebits hur stor den är och om den ska exekveras vid reset. Jag brukar använda http://www.siwawi.arubi.uni-kl.de/avr_p ... rprog_boot tillsammans med avrdude. Den har stöd för en mängd olika megor och kan triggas på några olika sätt vid uppstart tex serieport, pinaktivitet. Man kan även trigga den från huvudapplikationen.
Om du tar hem paketet så är det väl dokumenterat, ändra klocka, ändra cpu, trigger mm och kompilera, sedan är det bara att ladda ner med ISP till uC och sätta fuses.
Det går också att låsa bootloadern så man inte sabbar den.

[stekern]

Jag har gjort en uart-baserad bootloader med tillhörande laddningsprogram för AVR.
Den användes bland annat i ett temp/luftfuktighets-loggningsprojekt jag gjorde.

Kod kan du hitta här:
http://www.sk-electronics.com/svn/repos/usb-tahm/trunk/

bootloadern ligger under Firmware/bootloader
laddningsprogrammet är för linux och ligger under host/
I det här projektet användes en atmega168, men jag har även använt samma bootloader på en atmega644.

Sen till frågorna om setupen (johanb svarade förvisso dessa, men jag utvecklar lite).
Du har förstått rätt, huvudapplikationen ligger alltid på adress 0000, och bootloadern ligger i slutet av flashminnet (dess adress beror på hur stor bootloaderminnet är och detta sätts via fuses).
För att ladda bootloadern finns det 2 alternativ, ett är att sätta en BOOTRST fusen. Då kommer processorn starta på den adressen där bootloadern ligger efter en reset.
Det andra alternativet är att från huvudapplikationen hoppa till bootloaderadressen.
Jag använde båda alternativen i det ovanstående exemplet, bootloadern försöker då få kontakt med ett laddningsprogram under uppstart och den timear ut om den inte får kontakt.

Här kan man givetvis vara kreativ och tillexempel ha det så att en pinne måste vara satt för att bootloaderprogrammet skall laddas och så vidare.

[jesse]

tack för länkar och program.

stekern: jag gillar Linux, men i det här fallet måste jag nog tyvärr använda windows. Antar att din bootloader har "eget" protokoll, så det funkar inte med något av de andra bootloaderprogrammen?

Om jag kommer ihåg rätt så lägger man bootloadern i slutet på flashminnet

??? Märkligt, jag läste lite annan information i går kväll på nätet från en som verkade vara insatt:

1) man laddar bootloadern som ett vanligt program i flashminnet (det börjar då på adress 0x0000)
2) man anger med fuses hur stor bootloadern är. Då kommer Denna del av flashminnet att reserveras, och det övriga utrymmet (där sapplikationen ska ligga) kommer att börja med adress en 0x0000.
3) man kan välja med en fuse om man ska starta applikationen eller bootloadern. Bäst är kanske att den alltid startar bootloadern och att den har något sätt att avgöra om applikationen ska starta eller inte.

johanb: tack. ska kolla din länk.

[AndLi]

I stekern:s kod finns en funktion

Kod: Markera allt

void exit_bl() {
	(*((void(*)(void))0x000))();	/* jump to application */
}

Där ser det ut som att applikationen ligger på 0x000

Tittar man i databladet för ATMega168PA, sist i 26.4, figur 26.2 så ser man att bootloadern ligger sist i flashet och programmet från 0x00.

[jesse]

jo, men i och med att man skapar utrymme för bootloadern så flyttas adressen 0x000 upp så att applikationen rent fysiskt i flashminnet ligger efter bootloadern, fast den adresseras med 0x0000.

[AndLi]

Då skiljer sig ATMega644 och 48/88/168 på den punkten.

[jesse]

eller så har jag fått helt fel information. jag läste det här:

The procedure for installing a bootloader is indepenent of how the bootloader works:

1. Program the bootloader *.hex file into your processor using traditional methods (ie. AVR Studio, PonyProg, UISP, AVRdude, etc). Your AVR processor must match the one for which the bootloader is designed.
2. Set the size of your processor's bootblock to match the size of the bootloader program.
3. Set your processor's reset vector to point to the bootblock, not the default 0x0000 address.
NOTE: AVR Studio's notation for this is somewhat confusing. When the Boot Reset Vector Enabled box is checked, your processor will run the bootloader after reset. When this box is unchecked, the processor starts at the default 0x0000 address - ie. runs your application after reset.

EDIT: eller så har jag missuppfattat det?

Det förutsätts kanske här att det finns nån slags info i själva bootloadern eller makefilen som säger att den ska laddas sist i flashminnet? Jag uppfattade det som att man lägger bootloadern på adress 0x000 eftersom man "programmerar den som ett vanligt AVR-program"... och då kan den ju inte hamna sist i flashminnet, eller?

Sedan när man skapar bootsektorn så flyttas adressen 0x000 upp så att den hamnar efter bootloadern. Om man då programmerar igen med ISP (eller med bootloadern) så läggs det nya programmet på 0x000, alltså efter bootloadern?

Men jag kanske fattat detta fel? Jag ju ingen erfarenhet själv än.

[AndLi]

Informationen i ditt citat ser rätt ut, det är ditt antagande att hex filen alltid börjar på 0x000 som är fel.

Någonstans när bootloader hexen skapas har det styrts så att den landar i slutet av flashet.

[stekern]

Så är det, i t.ex. avrstudio ställer man in under memory att .text skall börja där bootloadern skall vara.
I mitt fall är det 0xC00 (och jag mindes fel, det var en atmega88 jag använt i mitt projekt)
Man kan även hitta detta i Makefile

Kod: Markera allt

LDFLAGS += -Wl,-section-start=.text=0x1800

(0xC00*2 = 0x1800)

[jesse]

aha, ok , nu fattar jag

[jesse]

Har laddat ner bootloadern från johanb:s länk (andra inlägget i tråden). Den har en makefil, men jag använder ju AVRStudio som gör sin egen makefil i en undermapp som heter "default" ... Hur som helst lyckas jag inte kompilera det hela i AVRStudio... Annars verkar den vara kanonbra. Jag behöver modifiera bootloadern lite, eftersom min UART är avstängd om jag inte sätter ett par utgångar, så den måste finnas som källkod.
EDIT: eller... det är PB1 som måste vara nolla (annars snackar den med en annan processor via UART istället för RS232 kontakten). Om bootloadern låter PB1 vara flytande (vilket jag antar är fallet) så skulle jag ju kunna sätta dit ett pull-down motstånd nånstans och därmed lösa problemet.

[jesse]

Hittade en väldigt bra och användarvänlig bootloader som heter chip45boot2. Den går att ladda ner som hexfil och det medföljer en bra manual samt en GUI för PC. Källkoden går att köpa om man vill modifiera den. Tar en minut att komma igång. Har just testat den på en av mina testkort med en ATmega324p.

[Johanb]

Ja den jag länkade till är gjord för gcc, tänkte inte på att någon använder något annat

[jesse]

Ja, nu använder visserligen AVRStudio också AVR-GCC, men det är själva progrsmmeringsmiljön i AVRstudio som blir krångligt då.