Proving the Read/Write to EEPROM Using PIC16F18877

Thread Starter

GettinBetter

Joined Jun 22, 2018
17
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;
  }
  //READ BACK TO LEDS
  do
  {
  for(i=0;i<8;i++)
  {
  PORTC = DATAEE_ReadByte(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

Thread Starter

GettinBetter

Joined Jun 22, 2018
17
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
 

Thread Starter

GettinBetter

Joined Jun 22, 2018
17
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:

Thread Starter

GettinBetter

Joined Jun 22, 2018
17
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
 

Thread Starter

GettinBetter

Joined Jun 22, 2018
17
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.
 

Thread Starter

GettinBetter

Joined Jun 22, 2018
17
(Edit for post #8: memory start address should read NVMADRH & NVMADRL not EEADRH & EEADRL)

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
10,480
(Edit for post #8: memory start address should read NVMADRH & NVMADRL not EEADRH & EEADRL)
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:

Thread Starter

GettinBetter

Joined Jun 22, 2018
17
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.
Appreciate the comments.

Les
 

Thread Starter

GettinBetter

Joined Jun 22, 2018
17
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.
My start address configuration (see EEPROM_Start_Address.jpg)
On starting the debugger, it shows the NVMADRH = 0x80, and not 0xF000, and NVMADRL = 0x00 as expected. (see Debug-01.jpg )
So why does it not write to the correct address? Maybe that's why there's no info in the build results.
Any thoughts people?


Build-01.jpg Silicon_Errata_and_Data_Sheet_Clarification.jpg EEPROM_Start_Address.jpg Debug-01.jpg
Regards
Les
 
Top