CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

PIC18F bootloader resets internal eeprom to 0xFF

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
samjith



Joined: 24 Aug 2016
Posts: 6

View user's profile Send private message

PIC18F bootloader resets internal eeprom to 0xFF
PostPosted: Wed Aug 24, 2016 7:18 am     Reply with quote

I am trying to use bootloader in my project and facing some issues with the internal eeprom. internal eeprom gets corrupted if I use bootloader but I don't see this issue without the bootloader. This is PIC18F6720.

I am using the below 2 example programs from CCS.
1. ex_bootloader
2. ex_intee

the bootloader hex is first flashed using ICD and then ex_intee hex is downloaded using SIOW serial program downloader. The ex_intee application program simply initializes 1,2,3,4 in EEPROM location using #rom directive and then reads it back in the main function and prints the data.

When bootloader is not used: (correct/expected output)
EEPROM:
01 02 03 04 ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff


When bootloader is used: (incorrect/unexpected output)
EEPROM:
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

I would like to know the reason why the bootloader corrupts the internal eeprom data?


application example code:
Code:

#define __PCH__

#if defined(__PCH__)
#include <18F6720.h>
#fuses HS,NOWDT,NOPROTECT,NOLVP
#fuses BORV45
#use delay(clock=20000000)
#use rs232(baud=38400, xmit=PIN_C6, rcv=PIN_C7)

#include <bootloader.h>

#include "stdlib.h"
#include <input.c>
#include "limits.h"
// The following initializes the first 4 locations of the data EERPOM
//  using the #ROM directive
#IF defined (__PCM__)
#rom 0x2100={1,2,3,4}
#elif defined(__PCH__)
#rom int 0xf00000={1,2,3,4}
//#define eeprom_start getenv("EEPROM_ADDRESS")
//#rom int eeprom_start={1,2,3,4}
#elif defined(__PCD__)
#rom 0x007FFC00={1,2,3,4}
#endif

#if defined(__PCD__)
 // dsPIC30F/dsPIC33F/PIC24 internal eeprom is 16bit wide
 typedef int16 INTEE;
#else
 typedef int8 INTEE;
#endif

void main() {

   unsigned int8 i, j, address;
   INTEE value;

   do {
      printf("\r\n\nEEPROM:\r\n");              // Display contents of the first 64
      for(i=0; i<=3; ++i) {                     // bytes of the data EEPROM in hex
         for(j=0; j<=15; ++j) {           
            printf( "%2x ", read_eeprom( i*16+j ) );
         }
         printf("\n\r");
      }
      printf("\r\nLocation to change: ");
      address = gethex();
      printf("\r\nNew value: ");
      value = gethex();

      write_eeprom( address, value );

   } while (TRUE);
}


Last edited by samjith on Wed Aug 24, 2016 1:31 pm; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19529

View user's profile Send private message

PostPosted: Wed Aug 24, 2016 8:11 am     Reply with quote

It's not.

It just won't write the EEPROM. 0xFF is the standard 'erased' contents.

The EEPROM is being erased when you load the bootloader program (which doesn't have the EEPROM set), and then is not written by the bootloader.

It's designed so that if you have configuration data in the EEPROM, this is kept, when you bootload a program.

In your programmer settings, there should be an option to not write/erase the EEPROM. Set this when you load the bootloader, and it the EEPROM won't be lost. If you want it to write the EEPROM, you would have to add code to the booloader to identify the EEPROM lines and use write_eeprom to write this data.
samjith



Joined: 24 Aug 2016
Posts: 6

View user's profile Send private message

PostPosted: Wed Aug 24, 2016 1:21 pm     Reply with quote

Thanks for your response,
I tried unchecking the Data EEPROM operation under settings tab in CCS Device Programmer but I see the same results:

The lines #rom int 0xf00000={1,2,3,4} in the application code is not having any effect while reading it in application. It reads 0xff instead of appropriate values. But if I write something using write_eeprom and read it back, it reads the correct value. It is just the #rom line not having any effect in the application code after including the bootloader code.
I am using compiler version 4.141

Thanks again,
Samjith
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Thu Aug 25, 2016 2:23 am     Reply with quote

Ttelmah wrote:
The EEPROM is being erased when you load the bootloader program (which doesn't have the EEPROM set), and then is not written by the bootloader.


It looks like this is what is happenning. The bootloader is not writing to the EEPROM, so it stays at its default, erased state, i.e. 0xFFs.

Most, if not practically all bootloaders will refuse to write the configuration fuses. The fuses for the bootloader must match those in the application. The fuses in application code hex image are ignored.

Many bootloaders will optionally write EEPROM, but not by default so you have to set some option. Unless you specify that EEPROM is not programmed, programming a bootloader into a PIC will erase the EEPROM back to 0xFFs. This is separate from whether the bootloader writes/erases EEPROM when it loads application code.

With bootloaded code like this, it is perhaps better to explicitily write to EEPROM in start-up code when you detect it is blank rather than use #rom to initialise it. You can also use this to reset to defaults when corruption is detected.
Ttelmah



Joined: 11 Mar 2010
Posts: 19529

View user's profile Send private message

PostPosted: Thu Aug 25, 2016 3:45 am     Reply with quote

Have to agree.

On most of my code, I have perhaps a structure declared to contain the EEPROM contents, and this has default values in it, and also a 'flag' (usually the first byte), set as '0xA5' or some similar 'marker' value.
Then on boot, the code checks the first byte of the EEPROM, and if it does not match the marker, then writes the default values from the structure. If it does match the marker, it instead reads the values from the EEPROM.

On not erasing the EEPROM, in the 'options' panel, you need to press the << button to get extra options, and then there is an 'erase mode' entry. By default it is set to erase the whole chip. Instead select the option 'erase only block in hex file'. With the Data EE un-ticked, it should then leave the EE as it is.
samjith



Joined: 24 Aug 2016
Posts: 6

View user's profile Send private message

PostPosted: Thu Aug 25, 2016 7:02 am     Reply with quote

Thanks for your response both.
I agree with the logistics on that.

I tried this sequence and it worked as expected:
1. CCS Device Programmer to flash the bootloader, make sure to uncheck the Data EEPROM under settings tab.
2. Load the application hex into the CCS Device Programmer, make sure to uncheck the program memory and configuration fuses under settings tab and just select the Data EEPROM. Flash the Data EEPROM code into the PIC.
3. Then use SIOW tool to transfer the application hex into serial bootloader.

Works great!

Thanks again,
Samjith
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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