| View previous topic :: View next topic |
| Author |
Message |
soonc
Joined: 03 Dec 2013
Posts: 215
|
| Loader.c Question |
 Posted: Wed Apr 03, 2019 10:05 am |
 |
|
In the CCS example code loader.c
Once the addr has been constructed the line which tests the addr seems to allow write to the bootloader area ! which could overwrite the bootloader...
| Code: |
if ((addr < LOADER_ADDR || addr > LOADER_END) && addr < getenv("PROGRAM_MEMORY"))
|
Is this correct ?
To protect the bootloader I suggest it it should be:
| Code: |
if ( addr > LOADER_END && addr < getenv("PROGRAM_MEMORY"))
|
Or did I miss something ?
Added Question:
Am I correct in thinking if I use the suggested code change it should also protect the interrupt vector table ... I'm using the PIC18F47K42 |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19369
|
|
| Posted: Wed Apr 03, 2019 10:23 am |
|
|
Think about it. What happens if it is between LOADER_ADDR, and
LOADER_END?. The result will be _false_ so it won't save the data.
addr has to be < LOADER_ADDR _or_ greater than LOADER_END for
the result to ever be 'TRUE'. So if it is between LOADER_ADDR and
LOADER_END, the result will always be false.
It is done this way, to be able to cope both with bootloaders at the
start of memory, and ones that are at the end of memory. Your test
would not allow these later type to work.... |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
|
| Posted: Wed Apr 03, 2019 10:31 am |
|
|
| Ttelmah wrote: | Think about it. What happens if it is between LOADER_ADDR, and
LOADER_END?. The result will be _false_ so it won't save the data.
addr has to be < LOADER_ADDR _or_ greater than LOADER_END for
the result to ever be 'TRUE'. So if it is between LOADER_ADDR and
LOADER_END, the result will always be false.
It is done this way, to be able to cope both with bootloaders at the
start of memory, and ones that are at the end of memory. Your test
would not allow these later type to work.... |
Good point.
For me I'm only considering bootloader at start of memory.
I recently had a BL failure during loading and can't figure out how it failed other then a bad write...
So doing only BL at start my suggestion should protect the BL code and interrupt vector table.
I guess this will work so long ad the interrupt code reside at the same locations for each update.
May be I should ORG the ISR's ?
Any suggestions ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19369
|
|
| Posted: Wed Apr 03, 2019 10:42 am |
|
|
Now, PIC's with vector tables are new/rare beasties (for PIC16/18's).
Not sure how the bootloader IRQ relocation will work for these. I'd
suspect CCS will have coded it to generate a relocation for every vectpr,
and it's relocation code is part of the bootloader, so it'll automatically
be protected, and the 'real' table will be part of the loaded code.
The key thing that makes the location test 'work' of course is it's use
of brackets, so it tests if the location is below the start or above the end,
and then combines the result of this with the test for being below the
end of memory. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
|
| Posted: Wed Apr 03, 2019 10:59 am |
|
|
| Ttelmah wrote: | Now, PIC's with vector tables are new/rare beasties (for PIC16/18's).
Not sure how the bootloader IRQ relocation will work for these. I'd
suspect CCS will have coded it to generate a relocation for every vectpr,
and it's relocation code is part of the bootloader, so it'll automatically
be protected, and the 'real' table will be part of the loaded code.
The key thing that makes the location test 'work' of course is it's use
of brackets, so it tests if the location is below the start or above the end,
and then combines the result of this with the test for being below the
end of memory. |
Thanks.... Still concerned as to why the BL failed. I've been using the CCS loader in other pics for years and not had any issues at all even with COMs loss the BL just restarts.
Of course I've tested this 47K46 BL by breaking COMs in the middle of a load session and have always been able to start over.
Any suggestions ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19369
|
|
| Posted: Thu Apr 04, 2019 2:56 am |
|
|
Can you describe more about the failure?. What happened?.
47K46?. No such chip.... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
