 |
 |
| View previous topic :: View next topic |
| Author |
Message |
rightbak
Joined: 16 Sep 2011
Posts: 10
|
| Bootloader and #rom |
 Posted: Wed Jun 07, 2017 2:54 am |
 |
|
PIC18F18325
MPLAB X v3.40
CCS v5.070
I am using the #rom command in my code to predefine some eeprom locations with data that that I want to use later.
| Code: |
#rom getenv ("EEPROM_ADDRESS")= {0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x55}
#rom getenv ("EEPROM_ADDRESS")+16={0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x80,0x05,0x05,0x14,0x00,0x00,0x00}
|
And I can see these same lines in the hex file it produces when I compile the code
| Code: | :10E00000000001000000000000000000000000000F
:10E0100000000000000000000000000000005500AB
:10E0200000000000000000000000000000000000F0
:10E030000000800005000500140000000000000042 |
I can then use the read_eeprom(n) command to read the eeprom as and when required. This works fine on a non-bootloaded version of code.
The problem is that when I include bootloader.h and bootload the code, I find that the bootloader hasn't bootloaded the eeprom locations, and the code is reading back 0xff instead of the pre-defined values.
I have traced the problem to this line of code in loader.c
| Code: |
if ((addr < LOADER_ADDR || addr > LOADER_END) && addr < getenv("PROGRAM_MEMORY")) {
|
The lines of code that predefine the eeprom are ignored by the bootloader because I think the address is not < "PROGRAM_MEMORY".
Is there a way to use the #rom command such that the bootloader will work with it? Is there a better way to do this? Many thanks for any help |
|
 |
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Wed Jun 07, 2017 3:19 am |
|
|
Many bootloaders do not write the eeprom (#rom) contents. Also, very, very few write the config fuses.
The reason is that EEPROM is usually used for things that must persist over activations of the application, such as settings, calibrations and stored content. Imagine if your phone forgot all your contacts every time it updated? For such applications, the app code must detect that the EEPROM is blank and write suitable defaults. This means that instead of using #rom and storing such data directly in EEPROM, it needs to be stored as constants in program memory.
Some bootloaders, for simplicity and minimal code size, don't even have code to support writing of the EEPROM. It can be added, but it may not be there in example bootloaders, such as those supplied with the CCS compiler, which are inherently simple and basic. Also not all PICs have EEPROM and the amount varies a lot from device to device, making a "one size fits all" booloader much more difficult. So, its often simply left out. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Wed Jun 07, 2017 3:42 am |
|
|
Also, the standard way to do this is to include the definitions in your code, and then check if the EEPROM has values to overwrite.
So (for example):
| Code: |
typedef struct {
int16 low_point; //Input minimum value
int16 high_point; //input maximum value
float output_min; //output minimum value
float output_max; //output maximum value
} s_scale;
s_scale scales[4] = {
{164,819,0.0,30.0}, //30 PPM 4-20mA
{164,819,0.0,14.0}, //0 to 14 0-20mA (Ph)
{0,1023,0.0,100.0},
{0,1023,0.0,100.0}
}; // default scales to apply to raw data
int8 offset 8;
|
Then you calculate a simple checksum for the data, add 'offset', and store this after the data in the eeprom.
On boot your code calculates the checksum of the ROM, adds 'offset', and tests this against the checksum in the ROM. If it matches it loads the values and overwrites the values in the code.
If it doesn't match, if stores these values to replace the current ROM contents.
Now this is where 'offset' comes in. If you want to program new values, you just change the 'offset' value used. The next time the chip boots, it calculates the checksum, and because the offset has changed, it won't match, so the values from the code will be written to overwrite the stored ones. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Thu Jun 08, 2017 12:54 pm |
|
|
| RF_Developer wrote: | | Many bootloaders do not write the eeprom (#rom) contents. Also, very, very few write the config fuses. |
And just to add to this, the reason bootloaders do not normally allow writing the config fuses is to
a. prevent accidentally bricking the device, and
b. a bootloader can't un-write a config fuse
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
|
|
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
