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


Closed Thread
Results 1 to 19 of 19
  1. #1
    Join Date
    Jul 2003
    Posts
    2,358

    Default 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

  2. #2
    Join Date
    Jun 2005
    Posts
    10


    Did you find this post helpful? Yes | No

    Default 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.

  3. #3
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

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

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  4. #4
    Join Date
    Jun 2005
    Posts
    10


    Did you find this post helpful? Yes | No

    Default

    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
    Last edited by atillotson; - 4th July 2005 at 17:09.

  5. #5
    Join Date
    Jun 2005
    Posts
    10


    Did you find this post helpful? Yes | No

    Default 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

  6. #6
    mytekcontrols's Avatar
    mytekcontrols Guest


    Did you find this post helpful? Yes | No

    Cool 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.

  7. #7
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    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.

  8. #8
    mytekcontrols's Avatar
    mytekcontrols Guest


    Did you find this post helpful? Yes | No

    Question

    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,

  9. #9
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    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...

  10. #10
    mytekcontrols's Avatar
    mytekcontrols Guest


    Did you find this post helpful? Yes | No

    Smile

    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?

    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.
    Last edited by mytekcontrols; - 11th July 2005 at 21:43.

  11. #11
    Join Date
    Feb 2004
    Location
    Germany
    Posts
    762


    Did you find this post helpful? Yes | No

    Default

    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:
    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
    regards

    Ralph

    _______________________________________________
    There are only 10 types of people:
    Those who understand binary, and those who don't ...
    _______________________________________________



  12. #12
    mytekcontrols's Avatar
    mytekcontrols Guest


    Did you find this post helpful? Yes | No

    Thumbs up

    Hi Ralph,

    Thanks for the link --- great info, especially this:
    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).

  13. #13
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    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 )

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

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  14. #14
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    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.

  15. #15
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Cool

    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) ?
    Last edited by mister_e; - 12th July 2005 at 05:21.
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  16. #16
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    Just Notepad as the editor.

  17. #17
    Join Date
    Feb 2004
    Location
    Germany
    Posts
    762


    Did you find this post helpful? Yes | No

    Default

    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.
    regards

    Ralph

    _______________________________________________
    There are only 10 types of people:
    Those who understand binary, and those who don't ...
    _______________________________________________



  18. #18
    mytekcontrols's Avatar
    mytekcontrols Guest


    Did you find this post helpful? Yes | No

    Lightbulb

    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).

    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 :-)
    Attached Images Attached Images  
    Last edited by mytekcontrols; - 12th July 2005 at 18:57.

  19. #19
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    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.
    Last edited by Demon; - 4th October 2016 at 19:17.
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

Similar Threads

  1. Can't read sequential addresses in external EEPROM
    By tjkelly in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 18th February 2010, 15:46
  2. Problem with I2C EEPROM addressing
    By Atom058 in forum General
    Replies: 14
    Last Post: - 3rd November 2009, 04:17
  3. Read/write variable into PIC internal eeprom
    By Pic2008 in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 13th August 2008, 08:06
  4. Multiple Pics accessing single EEPROM
    By Atom058 in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 3rd February 2008, 18:22
  5. word variable to 25lc640
    By TONIGALEA in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 6th July 2004, 20:59

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts