STM32F1xx vlastn bootloader

[Tomas Dresler]

Dovolil bych si uvest priklad doporuceny ST:

Bootloader je ulozeny na zacatku FLASH pameti (tj. adresa 0x08000000), po
startu je mapovany na adresu 0.
Vyhoda je ve vice vecech:
a) BL nelze prepsat, pokud je STM32 zamknuta proti cteni (první 4 sektory
jsou automaticky write protected), tj. můžete ho povazovat za bezpecny (!)
start systemu
b) BL je zodpovedny za overeni stavu aplikace uvnitř ci vne procesoru diky
HASH nebo CRC validaci, tj. i start a vyhodnoceni aplikace jsou bezpecne
c) BL při chybe CRC aplikace muze zustat v komunikacnim rezimu tak dlouho,
dokud nedostane platnou aplikaci
d) je to vas kod, takze můžete aplikovat sifrovani ci libovolnou sekvenci k
validaci na vstup nového programu
e) BL muze podporovat plne relokovatelny kod aplikace, takze ve FLASH
uložíte libovolne množství verzi programu a update lze delat i za behu
puvodni aplikace

Co se aplikace tyce, můžete se rozhodnout pro nasledujici scenare:

a) pokud je kod aplikace ve FLASH pouze jeden, bude umisteny na adrese
0x0800 0000 + pevny offset. Při startu procesoru BL overi platnost kodu,
precte si z vektor tabulky aplikacni inicializacni hodnotu SP a nastavi ji.
Jako druhy krok skoci na adresu Reset handleru. Aplikace potom v ramci
start-up kodu NASTAVI tabulku vektoru na svůj vlastní offset (Cortex-M3 to
umoznuje) a pak pozapina preruseni dle sve libovule.

b) pokud je aplikace plne relokovatelna (tj. pocitame s vice verzemi ve
FLASH), tabulku preruseni je potřeba umistit do RAM (typicky na jeji
začátek) a aplikace nebo bootloader si při startu spocita absolutni hodnotu
adresy vektoru a doplni ji do RAM. Aplikace potom při startu relokuje
tabulku preruseni do RAM.

Obe metody jsem aplikoval u zakazniku, vcetne vyrobcu ctecek platebních
karet apod., v ramci pametoveho modelu jsem pouzil další bloky FLASH pro
sifrovaci knihovnu sdilenou mezi BL a aplikaci apod.

V tomhle ohledu je Cortex-M3 (s nekterymi omezenimi i M0) vyborna platforma.
Registr pro  relokaci vektoru hledejte jako NVIC->VTOR
(http://infocenter.arm.com/help/topic/com.arm.doc.dui0552a/Ciheijba.html)

--
S pozdravem/With best regards

Tomas Dresler

-----Original Message-----
From: Hw-list [mailto:hw-list-bounces na list.hw.cz] On Behalf Of Miroslav Mraz
Sent: Saturday, May 17, 2014 3:51 PM
To: HW-news
Subject: Re: STM32F1xx vlastn bootloader

Teď jsem koukal, že může být aplikace totálně nefunkční a lze se z toho
vyhrabat i bez zásahu obsluhy. V bootloaderu použít watchdog s tím, že po
výstupu z něj občerstvování převezme aplikace. A pokud v ní bude zásadní
chyba, watchdog provede reset. Po resetu může bootloader zjistit z registru
RCC_CSR, že reset provedl právě watchdog, takže podruhé již aplikaci
nespustí a požádá o nový firmware.
Pokud ho po určitou dobu nedostane, zkusí aplikaci znovu spustit, protože
chyba nemusí být tak úplně kritická. Nic lepšího mě prozatím nenapadá, ale
tohle by mohlo chodit.

Mrazík

On 05/17/2014 11:36 AM, Jaroslav Buchta wrote:
> Jj, to je asi nejrozumnejsi reseni ktere jsem taky zvazoval (data bych 
> mel spis mimo procesor v nejake SPI flash ale to je jedno)
> Krome toho, ze nesmi vypadnout napajeni se taky nesmi stat, ze bude 
> nova aplikace nejak zasadne nefunkcni, ale co uz se da delat...
> Dalsi moznost me napadla napevno umisteny bootloader od 0, vektory 
> presmerovany do aplikace umistene za bootloaderem, dalo by se 
> prehravat bez ulozeni do mezipameti primo, v pripade selhani nebo 
> nefunkcnosti aplikace se nic nestane, bootloader bude fungovat po 
> resetu dal... To presmerovani vektoru je ovsem jedna nebo par 
> instrukci navic (u tech, co by vyuzival i bootloader, hlavne USB)
> Spis se zatim klonim k te druhe variante.
> Skoda, ze vektory nejdou presmerovat primo, jako treba u AVR

_______________________________________________
HW-list mailing list  -  sponsored by www.HW.cz
Hw-list na list.hw.cz
http://list.hw.cz/mailman/listinfo/hw-list