| View previous topic :: View next topic |
| Author |
Message |
wirelessage
Joined: 08 Aug 2012
Posts: 34
|
| bootloader LOADER ADDR issue |
 Posted: Wed Mar 27, 2013 9:46 am |
 |
|
Seems like I have to peel layers of onions with my bootloader code:)
I recently discussed an issue I had with my bootloader here:
http://www.ccsinfo.com/forum/viewtopic.php?p=173783#173783
My environment is as follows:
PIC18F2680
Using RS485 for downloading code.
Using CCS Compiler v4.092
Using CCS Bootloader client for downloading the firmware.
My next hurdle is as follows:
I am trying to understand what this line of code does in loader.c:
| Code: |
#if defined(__PCM__)
} else if ((addr < LOADER_ADDR || addr > LOADER_END) && addr < 0x2000){
#elif defined(__PCH__)
} else if ((addr < LOADER_ADDR || addr > LOADER_END) && addr < 0x300000){
#endif
|
My bootloader header file is as follows:
| Code: |
#if defined(__PCM__)
#define LOADER_END 0x1FF
#define LOADER_SIZE 0x1BF
#elif defined(__PCH__)
#define LOADER_END 0x8FF
#define LOADER_SIZE 0x5FF
#endif
#ifndef _bootloader
#if defined(__PCM__)
#build(reset=LOADER_END+1, interrupt=LOADER_END+5)
#elif defined(__PCH__)
#build(reset=LOADER_END+1, interrupt=LOADER_END+9)
#endif
#org 0, LOADER_END {}
#endif
int bootLoad; //used to know if my bootloader needs to run or not.
#locate bootLoad=0x100
|
The original hex file that is downloaded has the following lines as follows towards the end:
| Code: |
:020000040030CA
:0E00000000080B14008430000FC00FE00F400A
:00000001FF
|
When I went through the code, what it is doing for the lines above is:
1) line_type == 4
2) h_addr = 0x30
3) next line line_type == 0
4) addr = make32(h_addr,l_addr) which corresponds to 0x300000
In the loader.c code we have this magic number: 0x300000 and our condition is if( addr < 0x300000) then parse the line. So, the last few lines don't get parsed and written at all.
I can easily change the code to work by changing it to (addr <= 0x300000), but I need to know what is going on.
What is the signficance of this magic number 0x300000?
What is the code actually doing here? I can't seem to find this address in my code when I look up my .lst file.
Anyone see this? Doing something wrong here?
Thanks! |
|
 |
wirelessage
Joined: 08 Aug 2012
Posts: 34
|
|
| Posted: Wed Mar 27, 2013 9:51 am |
|
|
Just to clarify, by changing the code to
addr <= 0x300000 the client ends up writing to the firmware, but the software isn't booting. So, clearly this last few lines are important and it is doing something. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9182
Location: Greensville,Ontario
|
|
| Posted: Wed Mar 27, 2013 12:16 pm |
|
|
First do yourself a favour and if using the PCH compiler, edit the code to get rid of the conditionals...( if ...pcm, do this, if PCH do this).
It will clarify what's going on.
Usually CCS will have these conditionals so the code will compile with almost any series PIC/compiler combo.
The code tells the compiler where to 'stuff it' depending on the PIC you're using.Obviously PICs have different memory maps and 'conditionals' need to address this( no pun intended).
Basic PIC101...putting code into real memory as not al PICs have 64KW of code space!
hth
jay |
|
|
wirelessage
Joined: 08 Aug 2012
Posts: 34
|
|
| Posted: Wed Mar 27, 2013 2:04 pm |
|
|
I was trying to see what that 0x300000 refers to for PCH Compiler.
I just got a response from CCS.
For PIC18F2680 and other similar families, it is where the configuration data starts. That is what I wanted to know.
Since my bootloader already sets up the configuration data, I don't need to worry about what the hex file sends. The app that is downloaded just gets re-loaded.
Thanks! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9182
Location: Greensville,Ontario
|
|
| Posted: Wed Mar 27, 2013 5:37 pm |
|
|
Well maybe not 'worry' but be 'concerned'...depending on who wrote the bootloader, it is possible that the 'program' code could change the 'configuration fuses' to something other than what the 'bootloader' code does.
While I'm fairly certain CCS programs are fine...'bugs' do crop up, usually due to variations in PIC's memory maps, default bit settings, 'displaced' filenames,......
Just be sure to have good backups!
jay |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
