|
|
View previous topic :: View next topic |
Author |
Message |
JAM2014
Joined: 24 Apr 2014 Posts: 138
|
Issue using #Import directive |
Posted: Tue Jan 24, 2023 4:04 pm |
|
|
Hi All,
I'm trying to import a USB bootloader into my application code in order to make a single .hex file for production. The USB application works fine, and it works fine with a separate USB bootloader, but I'm having trouble combining the two with the #Import directive.
I've put a copy of the bootloader .hex in my application project directory, and I've added the #Import directive to my application as follows:
Code: |
#include <16F1459.h>
//#fuses PROTECT,MCLR,PUT,NOWDT,BROWNOUT
#fuses NONE
//Here we import the bootloader to make a single unified .hex file!
#IMPORT (FILE=high_usb_bootloader.HEX,HEX)
#use delay(int=8MHz, clock=48MHz, USB_Full, act=USB)
|
When I attempt to compile, I get this error:
Quote: | Line 6(8,42): Memory not available at requested location
|
My compiler version is v5.110
Thanks,
Jack |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19520
|
|
Posted: Wed Jan 25, 2023 2:18 am |
|
|
You don't show any directives to move this main code to clear what you are
importing. You need the same directives like those in ex_bootload.c
(adjusted to suit the size of your bootloader), so the main code is located
away from where the bootloader lives. You need this to be happening
_before_ any line that generates code (this includes the #use delay line).
#use rs232, #use delay, etc. etc, all need to be _after_ loading the relocation
commands (#include "bootloader'h" for the normal CCS setup).
You also need to limit the import to the loader size, otherwise other parts
will exist in the code that will clash. So:
#IMPORT (FILE=FILE=high_usb_bootloader.HEX,HEX,
RANGE=0:LOADER_SIZE)
The name suggests this is possibly a high memory bootloader?. If so
this will get even more complex, since the jumps at the bottom of memory
which are generated by the main, will need to be to the bootloader.
You would need to change the import range to be just covering where
the bootloader resides.
If this is a high memory bootloader, I have to say 'think again'. These are
not a 'good idea' on the PIC. Several reasons:
Because the memory has to be erased in pages, every time you reprogram
the bottom page using the bootloader, you erase the vector pointing
to the bootloader itself. Any fault here, and the chip is 'bricked'.
It is the low page that supports code protection for the bootloader.
If you ever want to use the ICD, this requires a small amount of memory
at the top of the program range. Result will clash with the bootloader if
it is here.
Some of the newer PIC's use the very top of the program memory for
the fuses. Again can clash.
On some chips, high memory bootloaders are favoured, but not on the
PIC.... |
|
|
|
|
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
|