# Proving the Read/Write to EEPROM Using PIC16F18877

#### GettinBetter

Joined Jun 22, 2018
33
Hi People, mature PIC & C Noob here,
I've worked through the LED Test progs (fine), Connected the EUSART/terminal (fine), switched the LEDs via terminal (fine), but my project will also require that I use EEPROM to store config data, so I thought I try a basic test....
Attempting to write some data to EEPROM and read it back, I'm getting some unexpected results. As my experience with C is limited (but I'm learning fast) I ask you guys to cast an eye over it. Any assistance would be appreciated.
Regards
Les
Code:
#include "mcc_generated_files/mcc.h"

/*
Main application
*/
void main(void)
{
// initialize the device
SYSTEM_Initialize();

uint8_t a;
uint16_t i;

TRISC = 0x00;
__delay_ms(1000); // wait for everything to stabilise

a=0x00;
//WRITE TO EEPROM
for(i=0;i<8;i++)
{
DATAEE_WriteByte(i, a);
__delay_ms(40);   // Double the suggested 20ms
a = a<<1;
}
do
{
for(i=0;i<8;i++)
{
__delay_ms(300);
}
}while(1);
}

/**
End of File
*/

Technical stuff :
Hardware
PIC16F18877 PDIP40
ICD3
ICD Demo Board
Ext PSU
Software
MPLABX vers4.10
XC8 Vers2.0
Tera Term Vers4.99

#### Attachments

• 176 KB Views: 5
• 2.3 KB Views: 4
• 11.8 KB Views: 8
• 11.8 KB Views: 4

#### joeyd999

Joined Jun 6, 2011
4,477

#### Sensacell

Joined Jun 19, 2012
2,754
It looks like you are writing zero to the first 8 EEPROM locations?
What is the problem?
What are you trying to do?

#### GettinBetter

Joined Jun 22, 2018
33
It looks like you are writing zero to the first 8 EEPROM locations?
What is the problem?
What are you trying to do?
Really!! Oh, I was hoping I'd set the variable all of them to 0, then set it to 1, in the loop, writing it to EEPROM, and then shifted it to the left each loop, giving me...
00000001
00000010
00000100
00001000
00010000
00100000
01000000
10000000

Then the reading loop is then used to set PORTC (with a delay) I was hoping the leds would repeatedly light in order.

It started off lighting the first four bits (0 to 3) then goes to some odd order with several alight at the same time, and at one point all light up.
Regards
Les

#### GettinBetter

Joined Jun 22, 2018
33
Ah, maybe that's it...I set it to 0x00 and just shifted the zeros :doh....testing

yes that was a partial problem, as I changed it, only to make it worse. Now we're back to the issues as stated in the last post.

Last edited:

#### GettinBetter

Joined Jun 22, 2018
33
Changed a = 0x00 to a = 0x01 in main.c

The actual LED lighting order is...
00000001 = RC0
00000010 = RC1
00000100 = RC2
00001000 = RC3
11111111 = RC (all)
00000010 = RC1
00111010 = RC0,2,4,5, & 6
10001000 = RC3 & 7

Regards
Les

#### Sensacell

Joined Jun 19, 2012
2,754
Have you used the debugger to go in and look at what is getting written to the EEPROM?

Everything step-by-step

You have two separate problems: read - write

#### GettinBetter

Joined Jun 22, 2018
33
Ok...
Using the debugger to look at what's being written to EEPROM gives me the following

i = 0 a = 1
i = 1 a = 2
i = 2 a = 4
i = 3 a = 8
i = 4 a = 10 = 00001010
i = 5 a = 20 = 00010100
i = 6 a = 40 = 00101000
i = 7 a = 80 = 01010000
... not what I expected, but lets assume that's being written to EEPROM. Now when reading back I should see a pattern of two leds move along the board, and at no time should all LEDs or RC7 light up.
What I find confusing is that in the data sheet (page 173) it says the EEPROM memory starts at F000 and is configured by EEADRH & EEADRL but in debug mode when I hover over the 'a' the intellisense text shows the first address to be written to is 0x77 which seems wrong to me, unless of course I'm reading it wrong.

#### Ian Rogers

Joined Dec 12, 2012
836
If your debugger depicts hex not decimal, it's working fine
0x01
0x02
0x04
0x08
0x10
0x20
0x40
0x80

is exactly what I would expect!!

#### GettinBetter

Joined Jun 22, 2018
33

So at least I'm attempting to writing to EEPROM.
I will need to check that EEPROM start address, amazingly there's very little info in the data sheet about EEPROM, all the examples/tables revolve around Flash Program Memory. As there are sections about NVM (which is what they both are) I should concentrate of those sections.

#### jpanhalt

Joined Jan 18, 2008
11,088
I will need to check that EEPROM start address, amazingly there's very little info in the data sheet about EEPROM, all the examples/tables revolve around Flash Program Memory. As there are sections about NVM (which is what they both are) I should concentrate of those sections.
I haven't used that chip yet, but I did get the development board of its kin. I have to disagree about the DS. There is a lot devoted to non-volatile memory, including EEPROM. Only the register names seem to have been changed to NVMREG etc. FSR access starts at 0x7000 and goes to 0x70FF. I believe the actual registers start at 0xF000 and the '7' simply tells FSRx where to go. Similarly, for the enhanced midrange devices, you need to set the the MSB of FSRH for program memory. Like I said, though, I have not used my development board yet and everything I say here is based on a brief review of the datasheet.

One thing you can do is to load the "NVMREG's (ne, EEPROM) while programming. That way you can test your reads. Here is what I do on a 16F1827:
Code:
DATAEE    ORG  0xF000
de 3                     ;index: 1, 3, 5, or 7
de low(416),high(416)    ;9600 baud, 0.16% bit error
de low(207),high(207)    ;19200 baud, 0.16% bit error
de low(103),high(103)    ;38400 baud, 0.16% bit error
de low( 51),high( 51)    ;76800 baud, 0.16% bit error
Thus, a read (i.e., 'brw' with w =0x00) returns the index, a read with the index (e.g., 'brw' = 0x03) returns low(d.207), then a bump to 0x04 returns high(d.207) and so forth.

Of course it may no longer be labeled DATAEE. That may not make a difference, since the location is what's important. Whatever it is labeled or preferred to be labeled is in the datasheet. One question I had early on, but was reluctant to ask because I didn't understand what you were trying to do, is why use EEPROM/NVMREG at all? If you are not changing and saving the values during run time, why not just include in program code as a table?

John

Last edited:

#### GettinBetter

Joined Jun 22, 2018
33
Hi John, My reason for using EEPROM is that I was hoping to (at some point) store the calibration data from a BNO055 gyro sensor. As this test is purely experimental (and I'm playing) so chip, implementation etc is all a bit fuzzy right now.

As for the rest of your comments, I'll have to read it a couple of times (dipping in & out of the DS), to make any sense of it due to my inexperience. I did read about ORG & DE in a post somewhere....didn't make any sense then.

Les

#### GettinBetter

Joined Jun 22, 2018
33
Hi Peeps,
Here's what I've got today, as I found another little window in the MPLABX that shows EEPROM, it also shows the start & finish address (F000 - F0FF).
On Clean & Build, the results show no sign of any EEPROM being used (see Build-01.jpg)
The Errata Data Sheet, says the EE memory is F000 - F0FF (see Silicon_Errata_and_Data_Sheet_Clarification.jpg)
So I'm happy that F000 is the start address, and for my test I'm only writing to eight adresses, so I won't worry about the EEPROM end address.