 |
 |
| View previous topic :: View next topic |
| Author |
Message |
rikotech8
Joined: 10 Dec 2011
Posts: 376
Location: Sofiq,Bulgariq
|
| Bootloader question |
 Posted: Mon Jun 01, 2015 7:45 am |
 |
|
Hello everyone.
Where the bootloader program resides in? The answer must be in flash.
Ok then it should reside at reserved space in flash where the application firmware can not interfere.
My assumption is that the bootloader is a program that acts as translator between serial communication interface and the flash memory, and each new firmware has to have an entry sequence to run the bootloader. Please correct me If I am wrong.
What is the procedure for jumping from application firmware to bootloader and vice versa?
Is it a program counter jump? If yes, what "kind of C code" does this jump?
I recently read about pointer to a function that resides at predetermined memory location. This expression sets the program counter to the flash addres 0x1000.
| Code: |
((void(*)())0x1000)();
|
Everything abovementioned might be far from the CCS approach for bootloader implementation, but may be some if you guys can enlighten me.
This is a discussion post rather than a problem. Each of you who would like to help me to understand the bootloader (in CCS prospective) is very much welcome.
Thank you.
_________________
A person who never made a mistake never tried anything new. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19360
|
|
| Posted: Mon Jun 01, 2015 8:22 am |
|
|
There are as many answers to this as questions...
Bootloaders can be done in dozens of different ways.
The 'standard' way on the PIC (constrained by the design of the chip), is that the bootloader sits at the bottom of the code memory, and it boots when the chip wakes up. It then tests for some specific condition to be true (usually something like an external jumper being present holding a pin high/low), and if this condition is not met, it jumps immediately to the relocated 'boot' location for the main code (above the end of the loader). It also re-vectors the interrupt calls in a similar way.
So it is never 'called'. It runs every time the chip boots, but the default is to do almost nothing.
Only if the hardware condition is met, does it instead run it's own main code, configuring the serial port, and starting to listen for instructions to reprogram the flash.
The 'interpreter' this involves (converts Intel hex normally), tests the address it is being asked to write, and does not accept this unless it is in the main area. Also the chips do in some cases have hardware write protection for an area at the base of memory. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
| Re: Bootloader question |
| Posted: Mon Jun 01, 2015 8:28 am |
|
|
| rikotech8 wrote: | Where the bootloader program resides in? The answer must be in flash.
Ok then it should reside at reserved space in flash where the application firmware can not interfere. |
Yes, that's correct.
The bootloader either is at the bottom of flash memory, with the application code being "offset" using #org, or at the top, in which case the reset vector of application code has to be altered, often by the PC code loader application.
In both cases, the bootloader will always run from reset. It then checks to see if there's any valid user code, and if so jumps to its reset vector. The bootloader generally has some way of knowing that the user code wants to be updated - that's what the special memory location is for: the user application writes some flag to teh special location and then resets the PIC. The bootloader runs, sees the flag has been set and so instead of running the application it goes into bootload mode to accept new code. Some bootloaders will look for some hardware related flag, such as a particular IO bit held low, or high, to decide when to go into bootload mode.
Where the special memory location is - often the last byte of EEPROM - and where and how big the bootloader are, depend on the PIC. Bootloaders also have to have the same fuses as the application code they are expected to run. All this means that bootloaders must be adapted to match the requirements of the user code and the PIC.
You don't have to use CCS bootloader code, or even program the bootloader in C. I've used Microchip AN1300 bootloader code, which is a high memory bootloader written in assembler and which I adapted to run with RS485 rather than RS232, to load CCS C application code. It worked fine.
Other folk will doubtless have more to say on this. Many people prefer low memory loaders, partly as many PICs have special code protect fuses to protect bootloaders. These require the application to be specially relocated to work with the bootloader. High-memory loaders do not, and if the bootloader doesn't use interrupts (most don't, but ones for CAN and other complex IO such as LAN and USB might) then the application code doesn't need altering at all by the user, though the reset vector has relocated, i.e. to the entry point of the bootloader, by something, but generally not by the user. |
|
|
rikotech8
Joined: 10 Dec 2011
Posts: 376
Location: Sofiq,Bulgariq
|
|
| Posted: Tue Jun 02, 2015 4:34 am |
|
|
Thank you guys.
_________________
A person who never made a mistake never tried anything new. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
