View previous topic :: View next topic |
Author |
Message |
theteaman
Joined: 04 Aug 2006 Posts: 98
|
Assigning code to various parts of memory with CCS |
Posted: Tue Feb 27, 2007 2:42 am |
|
|
Hello
I have a working system where I bootload code on an 18F. It is for firmware updates. I use the COLT bootloader.
The 'firmware update' code I compile and transmit contains code for reserving space for the bootloader (so as to not overwrite it):
Code: |
//reserve space for bootloader
#build(reset=0x800)
#build(interrupt=0x808)
#org 0x0000,0x07ff
void bootloader() {
#asm
nop
#endasm
} |
This has all been working fine. BUT...........
I would like to prevent someone from taking my HEX file (distributed over the net) and duplicating it on new PICs.
What would be great, is if I could store a few of my very important functions, that won't need firmware updating, along with the bootloader or in another code protected area of memory. The problem is, I don't know how to do this. For example, how would I call functions in the protected part of memory if the compiler doesnt know their addresses?
Thanks |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Tue Feb 27, 2007 8:58 am |
|
|
I think you simply #org the function in the protected memory and call
the function as normal. |
|
|
Guest
|
|
Posted: Tue Feb 27, 2007 4:51 pm |
|
|
treitmey wrote: | I think you simply #org the function in the protected memory and call
the function as normal. |
Hi Treitmey, thanks for the reply
Correct me if I'm wrong, but this solution would only work when the protected function is compiled WITH the non-protected functions. This would be counter-intuitive, because it would mean I'd need to distribute the firmware update hex file along with the protected functions.
What I want to do is:
1. use a PICSTART plus to write the bootloader hex file
2. use a PICSTART plus to write the protected functions
3. use RS232 to transmit the non-protected 'firmware update' code
Is this possible? Or is there a better way?
Thanks |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Tue Feb 27, 2007 5:01 pm |
|
|
Then in the firmware updates you compile with calls to a wrapper.(a function that doesn't do anything). They can "see" that your code is calling my_special_function(secret1,secret2) but the code for the function is not there. The problem is how the force the compiler to "reserve" that area so that the function address is always the same as are the functions compiled after it.
perhaps filling the function with noop to the same size as the actual function uses.
Code: | my_special_function(secret1,secret2){
delay_cycle(1);
delay_cycle(1);
delay_cycle(1);
delay_cycle(1);
delay_cycle(1);
} |
Maybe you'd be better off with an encrypted bootloader.
There are lots of options for that.
#id serial number.
then all data is xor'd with this serial number. something like that. |
|
|
Guest
|
|
Posted: Tue Feb 27, 2007 5:53 pm |
|
|
treitmey wrote: | The problem is how the force the compiler to "reserve" that area so that the function address is always the same as are the functions compiled after it.
|
Yes, thats right. I wonder if it is possible to use function pointers to do this? Ie. if I use #org X to place the function somewhere, can I then set the function pointer to X and call it?
Quote: |
Maybe you'd be better off with an encrypted bootloader.
There are lots of options for that.
#id serial number.
then all data is xor'd with this serial number. something like that. |
I can't actually find any encrypted bootloaders that work with 18Fs. I haven't been able to get the microchip bootloader working either (to add encryption myself), even though COLT is based on it. Can't find any instructions on how to use it.. (the datasheet seems to just provides an explanation on what it is)
Thanks |
|
|
Guest
|
|
Posted: Tue Feb 27, 2007 5:58 pm |
|
|
BTW, I'm aware that function pointers are not supported in CCS.. maybe there another way to achieve what I want? |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Wed Feb 28, 2007 8:48 am |
|
|
Encrypted bootloader. seems to be the best choice. |
|
|
|