Newsgroup: it.hobby.elettronica.digitale
Titolo: bootloader,perchè copiare tabella vettori applicazione in RAM?

Mi trovo a rifare una operazione che avevo già fatto,ma mi serve una 
rinfrescata
 
Ho un micro in cui gira una applicazione
voglio aggiungere un bootloader
 
la documentazione mi dice che la tabella vettori del bootloader va messa in 
una zona Flash protetta,ok,il bootloader deve essere solido
 
ma perchè mi dicono che la tabella dei vettori dell'applicazione va copiata 
in RAM?Se la tabella vettori dell'applicazione non deve essere modificata 
runtime non posso lasciarla in Flash?Alla fine è una lista di indirizzi a 
cui saltare dove trovo le varie routine che servono gli interrupt
 
Grazie 
 
 

 in RAM?
 
1) Perché la flash è lenta, e gli interrupt vanno serviti in fretta
 
2) Perché 9 su 10 la tua app avrà bisogno di modificare il vettore di 
interrupt, in una delle prossime versioni... e se lo lasci nella flash 
non potrai farlo più :-)
 

 non potrai farlo più :-)
Questa e' la ragione :-)
AA.
 
 
 

 potrai farlo più :-)
 
Anche qui non capisco,se non lo modifico runtime, ogni volta che  faccio una 
versione nuova  lo metto in un posto nuovo e basta.
 
Cosa mi sfugge? 
 
 

 versione nuova  lo metto in un posto nuovo e basta.
 
None. Primo perche' il tuo boot loader non e' (si suppone) linkato alla 
tua applicazione: per cui per interfacciarti alle sue funzioni di ISR
o altro dovresti predefinire una interfaccia 'nota' ad indirizzi
assoluti e dovresti riservarti la RAM necessaria a quelle funzioni.
Inoltre e' difficile che gli IRQ implementati nel boot soddisfino
tutte le necessita' dell' applicativo.
Per questa ragione con gli NPX e' possibile rimappare in modo
'trasperente' i vettori di interrupt da ROM a RAM.
Con altre architetture si lavora a 'manina' nel senso che
i vettori di interrupt del bootloader fissati in flash
sono dei semplici wrapper che poi richiamano la ISR tramite
una tabella di RAM.
 
 
aa
 
 
 


Non vorrei fare una cosa così come hai prospettato,ma:
 
All'accensione parte sempre il bootloader,se vede che nessuno ne chiede 
l'intervento
passa all'applicazione ,alla quale è legato tramite indirizzi assoluti 
,attenendomi a quanto  suggerito qui*
 
a questo punto l'applicazione non sa più cos'è il bootloader,e si arrangia 
con la propria tabella dei vettori,che per questo motivo continuo a 
pensare,forse erroneamente che possa stare in RAM
cosa dici-dite?
 
 
*
3.3 Prevent linking between bootloader and application
It is important to understand that good bootloaders should only interact 
with the application through absolute addresses. In
this case, the application reset vector resides at an absolute address, and 
the vector points to the entry point of the application.
The bootloader knows this absolute address, and to enter application mode it 
will use the application reset vector to jump to
the beginning of the application. This is important because every time the 
application is re-compiled, the linker might change
the address of the entry point. The bootloader does not need to know the 
changed address since the application reset vector
will always be at the same location and will always point to the application 
entry point.
Using a single project for both bootloader and application has the advantage 
of causing the device to be programmed only
once in production, as well as making debugging easier. However, having a 
single project also has some potential hazards if
the bootloader and application are linked together. It is important to 
prevent the linker from letting one section refer to a non-absolute address 
in the other section.
Consider this scenario: a bootloader is used with an ANSI library, and 
compiled in the same project as an application that
uses the same library. RevA of the firmware is compiled, and a library 
function, called MyFunc(), is linked into the
bootloader section at address 0x1000. The application also uses MyFunc(), 
and jumps into the bootloader when executing it.
RevA is released for production and everything works well. After some time 
passes, the firmware is updated to RevB. When
re-compiling the project, the linker moves MyFunc() to address 0x1005. The 
bootloader and application for RevB are linked
together, so this version works well as is. Now the firmware update for RevB 
is downloaded into a device with the RevA
bootloader. The application is updated to RevB, but the bootloader is still 
RevA. When the application executes and jumps to
MyFunc(), it jumps to address 0x1005. But MyFunc() in the RevA bootloader is 
at address 0x1000, and the code will run
away.
This example shows why linking between the application and the bootloader 
should always be avoided except through
absolute addresses. The only interaction this bootloader has with the 
application is when the bootloader launches the
application, which is done using the absolute address of the application 
reset vector. If the bootloader is included in the
application project, the linker should link only to a binary image of the 
bootloader, not to the source code or a library. With
this method, the linker will not be aware of the functions in the bootloader 
when compiling the application.
 
 
 

 ha scritto nel messaggio 
news:k8nmg7$r5k$1...@speranza.aioe.org...
 
ho già avuto il piacere di fare una breve conoscenza dell'ottimo(almeno così 
mi è sembrato,poi magari è lui che mi ha rubato le gomme)Marco Trapanese .
Voi di dove siete?Io  tra Mi e Bg
 
 

 mi è sembrato,poi magari è lui che mi ha rubato le gomme)Marco Trapanese .
 
 
Acc... mi hai scoperto! :)
 
Marco
 
 

 cosa dici-dite?
Yes, infatti e' cosi': la tabella dei vettori deve essere in RAM, 
altrimenti non potresti modificare quello che il  boot loader ha 
predefinito. Una volta attivata, l'applicazio e' come fosse partita
autonomamente :-)
Tra l' altro, anche il Kinetis ha la possibilita' di rimappare
i vettori di interrupt in RAM, proprio come gli NPX :-)
 
[MI< :-) >LC]
AA.
 

 predefinito.
 
ma fammi l'esempio di un caso in cui mi serva modificarla 
 
 

 ma fammi l'esempio di un caso in cui mi serva modificarla
 
Perche' non hai necessita di installare delle tue funzioni di ISR?
sei assolutamente sicuro che quelle cablate nel boot loader
ti bastino?
Per esempio io ho (su NPX) necessita' di avere vettori di gestione
CAN, UART , PWM etc.. ben diverse da quanto fatto nel boot loader :-)
AA.
 
 


si ma dimmi se sbaglio
 
 io  inizialmente non penso al bootloader,faccio l'applicazione , ,le sue 
tabelle dei vettori sono quindi in Flash all'indirizzo 0x4,per 
CAN,UART,PWM,Capture ecc,me la provo,e mi va bene,
poi dico ci metto un bootloader,quindi all'accensione mi troverò la tabella 
vettori del bootloader ,per cui la mia applicazione va compilata e linkata 
spostandola dopo lo spazio occupato dal bootloader,questo,ad ogni accensione 
parte,utilizzando la sua tabella vettori,e una volta verificato che 
l'applicazione è presente e non va aggiornata salta al vettore di reset di 
questa tabella,ricordandosi subito prima di puntare a quell'indirizzo il 
registro SCB_VTOR,che se non sbaglio fa parte del core ARM,e l'applicazione 
può continuare a gestire UART,PWM ecc da una sua tabella vettori in 
flash,magari sita all'indirizzo 0x8004
 
 
NB. le mie repliche hanno lo scopo di fare capire a me come funziona,non di 
dire che ho ragione io,quindi abbi pazienza se sono di dura cervice 
 
 


:-)
AA.
 

 AA.
Beh direi che i conti cominciano a tornare,
e anche se devo lavorare ancora un oretta penso che per essere un venerdě 
sera  siamo a posto, quindi grazie ancora a te a agli altri interventisti 
che sono intervenuti e buon fraidei naigt 
 
 

 che sono intervenuti e buon fraidei naigt
 
Premetto di non avere le competenze sufficienti per disquisisre su
piattaforme evolute (per me... Sigh!), ma credo che la necessità di
spostare la tabella vettori interrupt durante il bootloader (inteso
come riprogrammazione della flash) mi pare lapalissiano: durante la
riprogrammazione della flash si andrà a riscrivere anche la tabella
vettori e non è bello utilizzarla mentre viene sovrascritta.
Inoltre, se cade un interrupt durante la riprogrammazione, questo
dovrà far capo ed essere gestito al bootloader e non all'applicazione
in fase di aggiornamento.
Dato che anche il bootloader potrà essere aggiornato, sarà bene che il
codice risieda in RAM durante l'esecuzione, con annessi e connessi
(vettori int) per garantire che lo stesso sia rientrante (non
modificato durante l'esecuzione).
 
Piccio.

 che sono intervenuti e buon fraidei naigt
 
ciao
 
 
Premetto di non avere le competenze sufficienti per disquisisre su
piattaforme evolute (per me... Sigh!),
 
neanch'io,ma mi tocca
 
ma credo che la necessità di
spostare la tabella vettori interrupt durante il bootloader (inteso
come riprogrammazione della flash) mi pare lapalissiano: durante la
riprogrammazione della flash si andrà a riscrivere anche la tabella
vettori e non è bello utilizzarla mentre viene sovrascritta.
 
no perchè?L'unico programma che andrebbe  a toccare quell'area flash è il 
programma bootloader,che usa la propria tabella dei vettori,e scive il 
programma applicazione da tutt'altra parte.
 
 
Inoltre, se cade un interrupt durante la riprogrammazione, questo
dovrà far capo ed essere gestito al bootloader e non all'applicazione
in fase di aggiornamento.
 
Dato che anche il bootloader potrà essere aggiornato, sarà bene che il
codice risieda in RAM durante l'esecuzione, con annessi e connessi
(vettori int) per garantire che lo stesso sia rientrante (non
modificato durante l'esecuzione).
 
 
secondo me continui a vedere il bootloader come una parte 
dell'applicazione,invece ,almeno in questo caso è un programma indipendente,