Internal EEPROM Read/write Addressing Errors with 18F PIC's

Internal EEPROM Read/Write Addressing Errors with 18F PIC's

How do I get the internal EEPROM to store CORRECTLY into ALL loactions when using 18F series PICs?

A lot of debate on does it work, or doesn't it work? on this topic.

Yes, it DOES work. You need...

1. PBP Version 2.45 or later.
2. MPASM version v03.70 or later (part of MPLAB v6.50).

Typical Command Line to execute your compilation...

PBPW -p18F252 Myfile -ampasmwin

Nothing special in your program... use DATA, READ and WRITE commands just as you do for all your other 12 and 16 series PICs. If you don't believe me, here's a test program for you to run...

Code:

' Program ETEST.BAS ' ================= ' Writes incrementing values to internal EEPROM ' until Doomsday (or until EEPROM wears out!) ' ' Hardware Defines ' ================ ' ' LCD Display ' ----------- Define LCD_DREG PORTC ' Port for LCD Data Define LCD_DBIT 4 ' Use upper 4 bits of Port Define LCD_RSREG PORTC ' Port for RegisterSelect (RS) bit Define LCD_RSBIT 3 ' Port Pin for RS bit Define LCD_EREG PORTC ' Port for Enable (E) bit Define LCD_EBIT 0 ' Port Pin for E bit Define LCB_BITS 4 ' Using 4-bit bus Define LCD_LINES 2 ' Using 2 line Display Define LCD_COMMANDUS 2000 ' Command Delay (uS) Define LCD_DATAUS 50 ' Data Delay (uS) ' ' EEPROM Presets ' ============== Data @0,0,1,2,3,4,5,6,7,8,9 Data 10,11,12,13,14,15,16,17,18,19 Data 20,21,22,23,24,25,26,27,28,29 Data 30,31,32,33,34,35,36,37,38,39 Data 40,41,42,43,44,45,46,47,48,49 Data 50,51,52,53,54,55,56,57,58,59 Data 60,61,62,63,64,65,66,67,68,69 Data 70,71,72,73,74,75,76,77,78,79 Data 80,81,82,83,84,85,86,87,88,89 Data 90,91,92,93,94,95,96,97,98,99 ' Data 100,101,102,103,104,105,106,107,108,109 Data 110,111,112,113,114,115,116,117,118,119 Data 120,121,122,123,124,125,126,127,128,129 Data 130,131,132,133,134,135,136,137,138,139 Data 140,141,142,143,144,145,146,147,148,149 Data 150,151,152,153,154,155,156,157,158,159 Data 160,161,162,163,164,165,166,167,168,169 Data 170,171,172,173,174,175,176,177,178,179 Data 180,181,182,183,184,185,186,187,188,189 Data 190,191,192,193,194,195,196,197,198,199 ' Data 200,201,202,203,204,205,206,207,208,209 Data 210,211,212,213,214,215,216,217,218,219 Data 220,221,222,223,224,225,226,227,228,229 Data 230,231,232,233,234,235,236,237,238,239 Data 240,241,242,243,244,245,246,247,248,249 Data 250,251,252,253,254,255 ' ' Software Variables ' ------------------ CounterA var BYTE ' Address Pointer CounterL var WORD ' Loop Counter DataA var BYTE ' Read Data from/to EEPROM DataB var BYTE ' Expected Data from EEPROM DataOffset var BYTE ' ' Program Constants ' ----------------- MaxEEPROM con 255 ' Top address limit of EEPROM ' ' Initialise Program ' ------------------ TRISC=%00000000 CounterL=0 Pause 1000 ' ' Load Offset ' ----------- Loop: Read 0,DataOffset ' ' Read and Verify EEPROM Bank (256 Bytes) ' --------------------------------------- LCDOut $FE,1,"Reading=",#CounterL Pause 500 ' Need this to see above message For CounterA=0 to MaxEEPROM Read CounterA,DataA DataB=CounterA+DataOffset If DataA<>DataB then LCDOut $FE,1,"Error Loop=",#CounterL,$FE,$C0 ' ' Displays EEPROM Address, Expected Data, Read Data ' LCDOut "$",HEX2 CounterA," E=$",HEX2 DataB," R=$",HEX2 DataA Pause 1000 endif Next CounterA ' ' Increment DataOffset and write-Out EEPROM ' ----------------------------------------- CounterL=CounterL+1 LCDOut $FE,1,"Writing=",#CounterL DataOffset=DataOffset+1 For CounterA=0 to MaxEEPROM DataA=CounterA+DataOffset Write CounterA,DataA Next CounterA Goto Loop ' Do it forever End

If it doesn't work for you, check the versions of PBP and MPASM you're running... MPASM is FREE (a component part of MPLAB), so download and install the latest version regularly from the Microchip website.

Just a brief note on the operation of the above test program. If you Power-OFF your PIC whilst running this program during the WRITE cycle where it's filling the EEPROM with new values, the EEPROM contents will of course be corrupted. When you next Power-On, some values will be correct, and some will not be correct (the errors which will display accordingly on the LCD). Allow the program to complete it's READ cycle, it will then write-out a fresh EEPROM page which should then be read without error.

Melanie

On Board EEPROM - Read {address} above 255

Hi Melanie,
I was wondering if you could recommend a way to read an EE with an address above 255. It appears that the Read function is limited to 1 byte addressing. Even though I declare it a word. Have you found this to be true? F.Y.I. I am using 18f2620, And loving it.

Thanks ash
Sorry to bring up an old post.

it will work if you declare the Address variable as a word sized.

Hi Mr. E,
I tried that but it did not work. It still loops back after address 255.

I preload My eeprom with the EEPROM *reserved word

eeprom 192,["11"," "," "," "," "," "," "," "," "," "," "," "," "," "," "," "]
eeprom 208,["12"," "," "," "," "," "," "," "," "," "," "," "," "," "," "," "]
eeprom 224,["13"," "," "," "," "," "," "," "," "," "," "," "," "," "," "," "]
eeprom 240,["14"," "," "," "," "," "," "," "," "," "," "," "," "," "," "," "]
eeprom 256,["15"," "," "," "," "," "," "," "," "," "," "," "," "," "," "," "]
eeprom 272,["16"," "," "," "," "," "," "," "," "," "," "," "," "," "," "," "]
eeprom 288,["17"," "," "," "," "," "," "," "," "," "," "," "," "," "," "," "]
eeprom 304,["18"," "," "," "," "," "," "," "," "," "," "," "," "," "," "," "]

Im sending each line to an lcd and it works fine but i cannot reach EEPROM 256. Even though my address is 256 or above. and again my address varible is a WORD, not a BYTE.

Thanks Ash

That fixes it.

Oh, Well guess what?

ReadMenuData:
x = 2
for Z = Index4 to Index4 + 15
read Z,sendlcd[x]
x = x + 1
next Z
return

Index4 is a word like i said but Z was a byte.
I changed it to a word and wha-la

Thanks for your help.
That was a really stupid mistake on my part sorry for your troubles.

ashman

Preloading the EEprom with the DATA Command is a problem

Hi Melanie,

Just thought I'd throw in my 2 cents on this topic. If someone wants to preload the EEprom during the programming phase using PBP's DATA command, there is a PIC18F series problem. Dummy bytes (0) need to be inserted, and the address needs to be doubled (see below).

Code:

DATA @0,$08,0,$FE,0,$0F ' ATTR #00 DATA @6,$03,0,$FE,0,$0F ' ATTR #01 DATA @12,$02,0,$80,0,$0F ' ATTR #02 DATA @18,$04,0,$0E,0,$0C ' ATTR #03

Although this looks kinda weird, it will compile properly into the EEprom. This is only a problem with the preload function, and only with the PIC18F series (as far as I know).

This is a known bug by MEL, and they have acknowledged its existance.

The 18F EEPROM problem was fixed in v2.45 and with the latest releases of MPLAB (MPASM). You need to upgrade BOTH. See very first post on this thread.

Melanie,

Not to say that you aren't having success, and yes I did read your original post, and no I can't run your example because I have no LCD. However I do run a rather extensive EEprom preload of my own, and it doesn't work if I use sequential addressing with the DATA command.

Here is my system:

PBP ver 2.45A
Epic ver 2.44
MPASM ver 4.01
MicroCode Studio Plus ver 2.2.1.1
Windows 2000 Professional

Here is the code that does work (non sequential addressing w/dummy bytes):

Code:

'Text Generator 0 - Color and Enhanced Feature Attributes DATA @0,$00,0,$FE,0,$0F ' ATTR #00 DATA @6,$00,0,$FE,0,$0F ' ATTR #01 DATA @12,$00,0,$80,0,$0F ' ATTR #02 DATA @18,$00,0,$0E,0,$0C ' ATTR #03 DATA @24,$00,0,$8E,0,$0F ' ATTR #04 DATA @30,$00,0,$70,0,$0C ' ATTR #05 DATA @36,$00,0,$F0,0,$0F ' ATTR #06 DATA @42,$00,0,$7E,0,$0C ' ATTR #07 DATA @48,$00,0,$48,0,$0E ' ATTR #08 DATA @54,$00,0,$B0,0,$0F ' ATTR #09 DATA @60,$00,0,$28,0,$0C ' ATTR #10 DATA @66,$00,0,$16,0,$0F ' ATTR #11 DATA @72,$00,0,$30,0,$0C ' ATTR #12 DATA @78,$00,0,$9E,0,$0C ' ATTR #13 DATA @84,$00,0,$28,0,$0C ' ATTR #14 DATA @90,$00,0,$28,0,$0C ' ATTR #15 'Text Generator 1 - Color and Enhanced Feature Attributes DATA @96,$00,0,$FE,0,$0F ' ATTR #00 DATA @102,$00,0,$FE,0,$0F ' ATTR #01 DATA @108,$00,0,$80,0,$0F ' ATTR #02 DATA @114,$00,0,$0E,0,$0C ' ATTR #03 DATA @120,$00,0,$8E,0,$0F ' ATTR #04 DATA @126,$00,0,$70,0,$0C ' ATTR #05 DATA @132,$00,0,$F0,0,$0F ' ATTR #06 DATA @138,$00,0,$7E,0,$0C ' ATTR #07 DATA @144,$00,0,$48,0,$0E ' ATTR #08 DATA @150,$00,0,$B0,0,$0F ' ATTR #09 DATA @156,$00,0,$28,0,$0C ' ATTR #10 DATA @162,$00,0,$16,0,$0F ' ATTR #11 DATA @168,$00,0,$30,0,$0C ' ATTR #12 DATA @174,$00,0,$9E,0,$0C ' ATTR #13 DATA @180,$00,0,$28,0,$0C ' ATTR #14 'Text Generator 0 - Highlight, lowlight, and shadow color attributes DATA @186,$FF,0,$01 ' HighLight DATA @190,$DB,0,$00 ' LowLight1 DATA @194,$49,0,$00 ' Lowlight2/Shadow/Border 'Text Generator 1 - Highlight, lowlight, and shadow color attributes DATA @198,$FF,0,$01 ' HighLight DATA @202,$DB,0,$00 ' LowLight1 DATA @206,$49,0,$00 ' Lowlight2/Shadow/Border 'Horizontal and Vertical Start Position DATA @210,$10,0,$08 ' Horizontal - Vertical Offset 'Overlay Hue Setting DATA @214,$76 ' Hue (Text Generator 2 - Dac4) 'Fader Transparency and Time variables DATA @216,$63,0,$00 ' T_Level and B_Level DATA @220,$32,0,$32 ' UP_Time and DN_Time 'RTCC Time and Date Mode variables DATA @224,$00,0,$00 ' TimeMode and DateMode

And here is the code that doesn't work (sequential addressing):

Code:

'Text Generator 0 - Color and Enhanced Feature Attributes DATA @0,$00,$FE,$0F ' ATTR #00 DATA @3,$00,$FE,$0F ' ATTR #01 DATA @6,$00,$80,$0F ' ATTR #02 DATA @9,$00,$0E,$0C ' ATTR #03 DATA @12,$00,$8E,$0F ' ATTR #04 DATA @15,$00,$70,$0C ' ATTR #05 DATA @18,$00,$F0,$0F ' ATTR #06 DATA @21,$00,$7E,$0C ' ATTR #07 DATA @24,$00,$48,$0E ' ATTR #08 DATA @27,$00,$B0,$0F ' ATTR #09 DATA @30,$00,$28,$0C ' ATTR #10 DATA @33,$00,$16,$0F ' ATTR #11 DATA @36,$00,$30,$0C ' ATTR #12 DATA @39,$00,$9E,$0C ' ATTR #13 DATA @42,$00,$28,$0C ' ATTR #14 DATA @45,$00,$28,$0C ' ATTR #15 'Text Generator 1 - Color and Enhanced Feature Attributes DATA @48,$00,$FE,$0F ' ATTR #00 DATA @51,$00,$FE,$0F ' ATTR #01 DATA @54,$00,$80,$0F ' ATTR #02 DATA @57,$00,$0E,$0C ' ATTR #03 DATA @60,$00,$8E,$0F ' ATTR #04 DATA @63,$00,$70,$0C ' ATTR #05 DATA @66,$00,$F0,$0F ' ATTR #06 DATA @69,$00,$7E,$0C ' ATTR #07 DATA @72,$00,$48,$0E ' ATTR #08 DATA @75,$00,$B0,$0F ' ATTR #09 DATA @78,$00,$28,$0C ' ATTR #10 DATA @81,$00,$16,$0F ' ATTR #11 DATA @84,$00,$30,$0C ' ATTR #12 DATA @87,$00,$9E,$0C ' ATTR #13 DATA @90,$00,$28,$0C ' ATTR #14 'Text Generator 0 - Highlight, lowlight, and shadow color attributes DATA @93,$FF,$01 ' HighLight DATA @95,$DB,$00 ' LowLight1 DATA @97,$49,$00 ' Lowlight2/Shadow/Border 'Text Generator 1 - Highlight, lowlight, and shadow color attributes DATA @99,$FF,$01 ' HighLight DATA @101,$DB,$00 ' LowLight1 DATA @103,$49,$00 ' Lowlight2/Shadow/Border 'Horizontal and Vertical Start Position DATA @105,$10,$08 ' Horizontal - Vertical Offset 'Overlay Hue Setting DATA @107,$76 ' Hue (Text Generator 2 - Dac4) 'Fader Transparency and Time variables DATA @108,$63,$00 ' T_Level and B_Level DATA @110,$32,$32 ' UP_Time and DN_Time 'RTCC Time and Date Mode variables DATA @112,$00,$00 ' TimeMode and DateMode

I have compiled it both ways several times, and the sequential addressing example fails to work every single time (when I view the configuration menu that is part of my main program, I can see that the EEprom data is all messed up, also the video characteristics which are based on this data do not function properly).

I have also read the readme files that came with PBP 2.45, and no where is it mentioned that the EEprom problem was fixed in this version. However on the MEL upgrade page under the PBP ver 2.44 it lists: Changes PIC18Fxxxx DATA and EEPROM to allow odd locations (This would seem to suggest that the problem was fixed in ver 2.44 and not in ver 2.45, although the wording is strange).

Once again, I'm not saying you are wroung, but please tell me why you think it doesn't work in my situation.

Thank you,

Using PBP 2.45 and MPASM 4.01 with WinXP Pro, I can confirm the EEPROM works fine with 18F242, 252, 2420, 2520 and 2620. No blank spaces, odd and even locations accessed.

I have put product out in the field with internal EEPROM maxed-out... if there was any anomaly I assure you it would have been spotted.

I don't have or use Microcode Studio or EPIC.

What 18F is causing you grief? I'll order one in if I don't have it and give it a spin...

Perhaps the Epic programmer is the difference that really matters. I seem to recall something being said on the MEL site about the Epic programmer being involved with setting things right if the odd number sequence was used (unfortunately this topic was completely removed from the section it once appeared in on the MEL site). Perhaps the Epic programmer is now working against me, since the EEprom problem has presumably been fixed in PBP itself. Although once again, when I look at the upgrade info to version 2.45 for the Epic programmer nothing is mentioned about this at all.

Oh well. I can live with it for the time being, or at least until I get better confirmation on what is happening. However it would be nice to know, especially for other people's sake that may be trying to use the same combination of tools as I am (and tearing their hair out trying to preload the EEprom during compilation with sequential DATA addressing).

On a separate note: You said you don't use MicroCode Studio. What IDE are you using?

Quote:

What 18F is causing you grief? I'll order one in if I don't have it and give it a spin...

I am using a PIC18F252 Dip 28 package running a 10 Mhz xtal with PLL set to x4

Thanks for the quick reply and trying to help me out. It's appreciatted.

Michael,

I have experienced similar problems about a year ago.
See:
http://www.picbasic.co.uk/forum/show...ghlight=eeprom

It was fixed with one the updates.

And I can confirm what Melanie has already said:

Quote:

Using PBP 2.45 and MPASM 4.01 with WinXP Pro, I can confirm the EEPROM works fine with 18F242, 252, 2420, 2520 and 2620. No blank spaces, odd and even locations accessed.

I have tried it with the latest Versions of:
PICSTART+
ICD2
MicroCode Loader

Hi Ralph,

Thanks for the link --- great info, especially this:

Quote:

Once upon a time this was posted on the MEL site...
If you use DATA or EEPROM to load values into data space at program time, you will encounter inconsistency in the addressing of this data. The Microchip assembler won't address odd-numbered locations in data space. Therefore, you have to multiply the addresses in the DATA and EEPROM statements by 2. The EPIC programmer will correct the addresses at program time, so you can read the values back without the address doubling.

This is the info that I remembered, but could no longer find. It certainly appears that my problem might very well be directly linked to using the Epic programmer. If it is, what a Mickey Mouse solution that was (sorry Mickey, but I had to say it). I still would like to know if Epic ver 2.45 cures this before I upgrade (nothing else about the upgrade as published would be of benefit to me).

Hi Michael,
well the best way to know is probably to ask to Melabs.
One great guy there: Charles Leo => [email protected]

But i doubt that you'll encounter any other problem with an upgrade.

I just finish to talk to Mr Mickey Mouse... he's still happy. More and more publicity for him will just increase his pay cheque... well that's what he told me :o)

Michael St-Pierre=> is there any french language back to it?

Well 18F252 I've got here and use it often to interchange between 16F876. I can most certainly tell you there's no EEPROM issues.

>> What IDE are you using?

I've never felt the need for an IDE which is why I don't use one. It's an aid for those that lose track of what their program is trying to do - and that's worrying! At any point in your program, you should know what the state of the nation is. If you start relying on aids as a nescessity, then like with radar, it still won't stop you hitting submerged rocks.

Quote:

Originally Posted by Melanie

It's an aid for those that lose track of what their program is trying to do -

If we talked about an ICD i'd agree... but for an IDE...

Melanie, i think the Michael's question could also be: What are you using to edit/compile your code(notepad or worst MPLAB) ?

Just Notepad as the editor.

Quote:

Originally Posted by Melanie

If you start relying on aids as a nescessity, then like with radar, it still won't stop you hitting submerged rocks.

Or get a Sonar in addition to the Radar!

I agree with Melanie,
you shouldn't be fishing in muddy waters,
your navigation should always be is clear
and at any point in time you should know where you are.

1 Attachment(s)

Hmmm... interesting point of view on IDE's. At least for me, I really like the ease of use, being able to have everything available in one application which brings together all the previously independent parts. And as to the idea of knowing where I am; I see nothing wrong with having the radar available.

Before the IDE's were available, I wrote a batch file menuing system to try to do some of the same things. It worked to some extent, and did make it easier to navigate between the various apps (editor, assembler, and programmer), but I wouldn't call it an IDE. Now in my case, I never use the interactive aspect of the IDE, and opt instead to debug and monitor in other ways on the real hardware. Usually most of my applications have either RS232 or video output, so I use these as my windows to see inside, and to monitor my own custom breakpoints (if needed).

Anyway this is not really inline with the topic we are addressing here, but it is interesting none the less.

Now back to the EEprom issue...

Steve thanks for the suggestion on contacting Charles at MEL. As it turns out it is indeed an EPIC related problem. But it is something that can be easily corrected, and has been provided for within the EPICWin application (not so Mickey Mouse after all).

Here is an email response I got back from Charles (very speedy response I might add).

Quote:

The problem has been fixed in your version of EPICWIN, so an upgrade probably isn't necessary. (Though the new meProg software version 3.30 will also fix the problem and give you some new features.)

In EPICWIN, there is an option called "18Fxxx File Data Address * 2". This changes the way the software adjusts the EEPROM addresses that it reads from the hex file. Its purpose was to offer compatibility with older versions of PBP which used only even-numbered locations. I believe you should uncheck this option (in the Options menu of EPICWIN).

To test, put a simple EEPROM directive in your code:

EEPROM 0, [0, 1, 2, 3]

Compile for an 18F part, open the hex file in EPICWIN, and View the Data EEPROM. Change the option above and reopen the hex file to see the result in the Data EEPROM window. Try it both ways until all the data is shown in the window after you open the file.

There are downloadable versions of software here:
http://melabs.com/support/progsoft.htm

Regards,
Charles Leo
microEngineering Labs, Inc.

I have also included a graphic that gives a better idea of accessing the option that Charles described.

Edit: I almost forgot. I tested this out in my application, and YES unchecking the "18Fxxx File Data Address * 2" option does allow me to use standard sequential addressing when using the DATA Command.

No Parlez-Vous Français here :-)

Quote:

Originally Posted by mytekcontrols

No Parlez-Vous Français here :-)

Well as i know a few person like me, Demon, Acetronic, Matarse and probably there's a few much...

Great to know it's work for you now.