Electronic – difference between POR and other resets

To test all below I used MPLAB 8.76, compiler XC8 ver 1.30:

First a digression/advice: If you have switched to PIC16F690 recently: ~ 6 weeks ago I decided to abandon this chip, except for really small projects. It has little FLASH, little RAM and only 256 EEPROM. And you can not debug it easily on real target. I use 18FK4620 now: it has 16 times as much FLASH (64kB) , 4 times more EEPROM (1kB), and almost 16 times RAM (~ 4kB), it can run at up to 64MHz Fosc (!), plus more ports, etc.

And the MOST IMPORTANT: you can DEBUG 18F46K20 using standard PICKIT2 and MPLAB 8.76 ... 8.91 (I do not use MPLAB X yet, as I heard a lot of bad stories about it). And you do not need any extra interface boards etc. Just your target board --> PICKIT2 (i.e. you do not have to switch to a mishap PICKIT3)

And price is very similar: 18F46K20 is ~ $2.90 and 16F690 is ~ $2.40 in retail.

NOW SOLUTIONS FOR YOU:

---------------------- Solution 1a: Use something like this (and change '20' to the array size you want):

__eeprom unsigned char my_eeprom_values[20] =  
        {   0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x20,
            0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x30};**

But if you use the above then you do NOT know where compiler will place these in EEPROM. (Note though that __eeprom qualifier is ignored by XC8 compiler for many PIC18Fxxx devices)

---------------------- Solution 1b:

const unsigned char abc1 @ 0x2100 = 0x11; // @ EEPROM addr = 0
    // ......
    const unsigned char abc2 @ 0x2110 = 0x22; // @ EEPROM addr = 17**

Note that it looks that EEPROM in 16F690 starts at addr. 0x2100 (not 0xF00000 as you mentioned). I checked .map file after build. I also checked the result of the above after compiling the code and then I viewed the EEPROM using PICKIT2 (or if you debug under MPLAB using MPLAB SIM, then after you build the code, go to Menu -> VIEW -> EEPROM). You will see al data there as desired.

---------------------- Solution 1c:

You can mix (1a) and (1b) above, you can use 'int' instead of 'char', but : - be aware that because __EEPROM_DATA does not allow to specify the eerpom address, one statement will overwrite some of the other ones. To illustrate this I placed 0x99 in locations that WOULD be overwritten. XC8 warns about this anyway - see the end of my post. - Endian that XC8 uses 'swaps' bytes OF 'int' type: the below 'abc' data will be stored as : 22114433, instead of as 11223344.

---------------------- EXAMPLE:

Here is a tested example for 16F690 under XC8 ver 1.30:

    const unsigned int abc1 @ 0x2100 = 0x1122;
    const unsigned int abc2 @ 0x2102 = 0x3344;
  __EEPROM_DATA(0x99, 0x99, 0x99, 0x99, 5, 6, 7, 8);
    const unsigned int abc3 @ 0x2108 = 0x5566;
    __EEPROM_DATA(0x99, 0x99, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88);
    __eeprom unsigned char my_eeprom_values[20] = \ 
    {   0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x20,
        0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x30};

Resulting EEPROM CONTENTS is this:

22 11 44 33 05 06 07 08 66 55 83 84 85 86 87 88
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
27 28 29 30 FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF ...

So 0x(22 11 44 33) have overwritten 4 x 0x99. Same with 0x(66 55). But note that the rest is just a plain copy of data in C code.

---------------------- Solution 2: 'yours': Just as you said place as many '8 byte' long __EEPROM_DATA statements as you need. What's wrong with this ? It is simple and works always. Compiler places data in the order you will have them in your C code. If you need some bytes to be unchanged then place 0xFF for them. Eg.

__EEPROM_DATA(0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF);  // addr: 0x00 ... 0x07 
__EEPROM_DATA(0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88);  // addr: 0x08 ... 0x0F
__EEPROM_DATA(0x55, 0x66, 0x87, 0x65, 0xFF, 0xFF, 0xFF, 0xFF);  // addr: 0x10 ... 0x17 
etc.

During build in (1b/1c) XC8 compiler gives these warnings:

.... object "_abc1" lies outside available code space

... (1343) hexfile data at address 0x4200 (0x99) overwritten with 0x22 

but I got data I wanted in EEPROM where I wanted it so I don;t care.

Memory Summary: Program space used F00h ( 3840) of 1000h words ( 93.8%) Data space used E4h ( 228) of 100h bytes ( 89.1%) EEPROM space used 24h ( 36) of 100h bytes ( 14.1%) ...

-end-

According to the data sheet:

The WRERR bit is set when a write operation is interrupted by a Reset during normal operation. In these situations, following Reset, the user can check the WRERR bit and execute the appropriate error handling routine.

That means the only time you should really be looking at the WRERR bit is at the start of your program to see if a reset occurred during a write operation. If it did, then you know you can't trust the contents of the memory you wrote. You should then run an error handling routine, which might scan the area of memory that you write to looking for any rows that are part-written, don't have the right checksum, etc, and doing something "appropriate" with them, such as replacing them with valid data, erasing them, whatever is right for your software.

The proper way to know if the row you have written has been written correctly is to read the row in and compare it to what you have told it to write, and if they differ then something went wrong (typically you have worn out your flash and you need to replace the chip).