EEPROM Variables (EE_Vars.pbp)

[brittons]

I've been experimenting with EEVars. I downloaded the program using Microcode Studio with the ICD. I enabled debug and let the program step into EE_Vars.Pbp. I watched the EEProm values get set with 511 as the EE_start. All my EE variables were set to default values and everything was fine. After everything was complete and my last variable was done EE_start has the value '17h' in it. So I stopped the program. Unplugged my power to my processor. Plugged it back in and restarted the ICD without downloading the program again. I paused at the first line:

goto OverEEsubs ; Skip over subroutines

I then changed the value of my first EE_var from 'FFh' to 'A4h' and started single stepping again. I am expecting that the 'First Run' had set all values to default and now the values would be read into my variables but no longer set to defaults on power up.

Instead the EE_start value is set to zero, followed by my first EE_var at location EE_start + 1 is reset to 'FFh' and the whole process starts over again. Am I misunderstanding something about how EEVars works? Here is an example of how I define my first variable. All others are the same.

EEStat VAR BYTE:@ EE_var _EEStat, BYTE, 255

How does EEVars know not to set default values on subsequent power ups? Maybe this would give me some insight. I assumed it looks at EE_start to see if it is not equal to 255 or 0.

Thanks, Bob

[Darrel Taylor]

Sheesh, don't hesitate to ask questions if you have any ...

OK, let's start with the last one ...

How does EEVars know not to set default values on subsequent power ups? Maybe this would give me some insight. I assumed it looks at EE_start to see if it is not equal to 255 or 0.

Nope, when the chip is initially programed, the EEPROM EE_Start, [0] statement causes the programmer to load the 0 value into the EE_Start location of EEPROM (511 in your case). This only happens during programming. It can't zero it out at run-time.

Then every time the chip resets, it runs through the list of EE_vars counting them as it goes. If the EEPROM value at 511 is less than the variable count, then it knows it hasn't initialized that EE_var yet and will write the default value, and increment the value at EE_Start.

This way, if power is lost in the middle of the first initialization, it can tell that the init was not completed, and continue from where it left off.

All writes are self-timed. So no, you don't need pauses between successive writes.
All writes are verified after writing. If the value in EEPROM is not the value it tried to write ... it will retry up to 10 times to get it to write correctly, and on the last attempt will disable Global interrupts before trying. Then if after 10 tries it still doesn't verify ... the EE_Failed bit will be set. This would be a good bit to watch in the ICD. If it gets set, the configs probably have _WRTD_ON_6H, or in your case the bootloader.
<hr>

Plugged it back in and restarted the ICD without downloading the program again. I paused at the first line:

goto OverEEsubs ; Skip over subroutines

I then changed the value of my first EE_var from 'FFh' to 'A4h' and started single stepping again. I am expecting that the 'First Run' had set all values to default and now the values would be read into my variables but no longer set to defaults on power up.

When it gets to that point, absolutely nothing has been done yet.
The real work isn't done until the program encounters the variable declarations with the matching EE_var macros. Those macro's are what initialize the variables, so you would need to stop somewhere after the variables to see how it powered up, before changing any values with the ICD.

And again, if your program jumps over those variable declarations, nothing gets initialized.

[brittons]

Hi Darrel, really sorry about the barrage of questions. I have a problem I'm having a hard time solving. I love the EE_Vars program and it is making things easier but I have this reset problem and since I must be missing something I don't know who else to ask. I'm sure it's something on my end. I have been setting breakpoints, single stepping and trying to track it down but so far it's still there.

I'm not sure what you meant by:

'the configs probably have _WRTD_ON_6H, or in your case the bootloader'

From what I can see in Microcode studio all the vars are properly written to EEProm and to the associated variables.

I'll keep at it, thanks for all or your help.

[brittons]

Well, I have another question. I have been examining the .asm and .lst files to try to understand how macros create code and better grasp the EE_vars program. I found a variable called EE_VarCount that is EXT (external?) which I believe means it is not available in the actual downloaded code.

Can help me better understand what happens when the EE_Vars program is run the 2nd time after initialization is complete? I understand that:

EEPROM EE_Start, [0]

Sets EE_Start to zero on 'first run' only. At the end of initialization EE_Start contains the number of EE_Vars assigned. After that I assume that EE_Start is never written to correct? Can you give me some insight into what the program does on 2nd and consecutive runs. What is it examining to know that it is finished with initialization? Is there a variable I can look at to know to see what happens?

Thanks again, Bob

[Darrel Taylor]

I found a variable called EE_VarCount that is EXT (external?) which I believe means it is not available in the actual downloaded code.

If you do a FIND (ctrl-F) and type in EE_VarCount, you'll see that variable used many times in the program. So yes, it IS in the actual downloaded code.

Can help me better understand what happens when the EE_Vars program is run the 2nd time after initialization is complete? ...

I already went through that in post#38.

I understand that:
EEPROM EE_Start, [0]
Sets EE_Start to zero on 'first run' only. At the end of initialization EE_Start contains the number of EE_Vars assigned. After that I assume that EE_Start is never written to correct?

Correct.

What is it examining to know that it is finished with initialization? Is there a variable I can look at to know to see what happens?

Again, it's looking at the EEPROM location designated by the EE_Start constant. (post#38)

Look, we can go round and round trying to blame the Tried and Tested code (EE_vars), or we can try to find the problem in your program, which you seem to have stopped looking at.

You get to see all my code.
I need to see yours.
The whole thing, not just 10 lines somewhere that might apply.
<br>

[Darrel Taylor]

Hi again Bob,

After another similar question from a different user, I've found a possible reason for your problems.
Of course, there's no way to verify it because I still haven't seen your code, but ...

Something I didn't realize before is that the DATA and EEPROM statements use the same internal "counter" to keep track of the next available EEPROM location.

So if the EE_start location is changed to a higher value, and DATA statements come AFTER the EE_vars include file, then the DATA statements will place the data in the same locations that EE_vars uses, instead of 0 like expected.

In other words, to do what you were trying to do, the DATA statements would have to be placed PRIOR to including the EE_vars module.

hth,

[LinkMTech]

Hi Darrel,
I'm just beginning to use the EEPROM of the PIC12F683 on the LAB-X4 platform with PB Pro 2.47 and using the MPASM compiler.
I downloaded the EE_Vars.PBP.txt file and copied it to my PBP folder where I resaved it as EE_Vars.PBP, I think I did right.
The good stuff:
I also download your EE_example_1 file to experiment with. After configuring the LCD setup, it works as advertised!

'****************************************************************
'*  Name    : EE_1_Example.bas                                  *
'*  Author  : Darrel Taylor                                     *
'*  Date    : 8/27/2005                                         *
'*  Version : 1.0                                               *
'*  Notes   : This is an Example program for the EE_Vars.PBP    *
'*          : Include file.                                     *
'****************************************************************
@ __config _INTRC_OSC_NOCLKOUT & _WDT_ON & _MCLRE_OFF & _CP_OFF 
OSCCON = %01110001  ' Osc 8Mhz
ANSEL = %00111000	' Fosc/64 and ANS3 set to analog
ADCON0 = %10001100  ' Right justified and AN3 selected
CMCON0 = 7		    ' Analog comparators off
GPIO = %00111101    ' Set all ports to inputs except port 1
TRISIO = %00111101  ' Port 1 to output, rest inputs

;-- Define LCD connections -- (change these to match your hardware) ------------
Include "modedefs.bas"	' Mode definitions for Serout
INCLUDE "EE_Vars.PBP"           ; Include the EE_var routines

define OSC 8          ' Declare for PAUSE and PAUSEUS statements
pause 1000
'=========================================================================
'                         Variable pin names
'========================================================================= 
'       Var GPIO.0      ' Pin 7
LCD 	Var	GPIO.1	   	' Pin 6
'       Var GPIO.2      ' Pin 5
'       Var GPIO.3      ' Pin 4
'       Var GPIO.4      ' Pin 3
'       var GPIO.5      ' Pin 2



Days    VAR WORD  :  @  EE_var  _Days, WORD, 365
Cats    VAR WORD  :  @  EE_var  _Cats, WORD, 1024
Mice    VAR WORD  :  @  EE_var  _Mice, WORD, 10000
PowerOn VAR BYTE  :  @  EE_var  _PowerOn, BYTE, 0

PowerOn = PowerOn + 1           ; Increment number of Power-On cycles
@ EE_write_var  _PowerOn        ; save the new number to EEPROM

Serout LCD, T2400, [$fe, 1]	' Clear screen
pause 1000
Serout LCD, T2400, ["Days= ",#Days," Cats= ",#Cats]
pause 100 
Serout LCD, T2400, [$fe, $c0,"Mice= ",#Mice," PowOn= ",#PowerOn]
pause 100

RANDOM Mice                     ; get a new value for Mice
@    EE_write_var  _Mice        ; save it to EEPROM

stop

The funny stuff:
If I first select and copy any one of the EE variables such as:

PowerOn VAR BYTE  :  @  EE_var  _PowerOn, BYTE, 0

and change the Byte to a Word in both cases here, it gets mad when I compile it and reports these errors:

Error[113] c:\program~on and on~ee_1_e~.asm 163: Symbol not previously defined (Byte)
Error[113] c:\program~on and on~ee_1_e~.asm 172: Symbol not previously defined (Byte)
Error[113] c:\program~on and on~ee_1_e~.asm 173: Symbol not previously defined (Byte)

So now if I change it back to BYTE in both cases, it still gets mad after compiling.

Here's the stranger part: I now select the troubled line of code and paste the original line of code prior to all this and the compiler is happy once more!?

I only tried this because when I wrote my own and got these messages, they stopped when I commented out my EE declaration lines and "pasted" your lines instead.

Are you using subliminal texts for this routine? Or did I not copy the Include file properly into my program?

[Darrel Taylor]

Watch the CASE of the parameters.
Use WORD or BYTE instead of Word or Byte.

You can tell from the error message ... Symbol not previously defined (Byte).
<br>