18F252 internal EEPROM / DATA, READ

Looks like I ran into the next trap.

on the 16F876 I have been using the DATA Statement to write data to the internal EEPROM and it worked as expected.

i.e.

DATA @$10,$A1,$A2,$A3,$A4,$A5,$A6,$A7

results in the following EEPROM content at location $10

$0010 - A1 A2 A3 A4 A5 A6 A7



with the 18F252 it looks different

DATA @$10,$A1,$A2,$A3,$A4,$A5,$A6,$A7

results in the following EEPROM content at location $08

$0008 - A1 A3 A5 A7


Does a READ have the same strange behavior on the 18F ?


Could anyone give me some hints how to use DATA and READ with the 18F252 (PBP 2.43 / MPASM 3.50)



Thanks in advance !

I have done some testing:

To write data to the internal EEPROM using the DATA or EEPROM statement
there appears to be some kind of workaround:

DATA @$20,$A1,0,$A2,0,$A3,0,$A4,0,$A5,0,$A6,0,$A7,0

or

EEPROM $20,[$A1,0,$A2,0,$A3,0,$A4,0,$A5,0,$A6,0,$A7,0]

will result in the following EEPROM content starting at location $10

$0010 - A1 A2 A3 A4 A5 A6 A7

So what you need to do is:

multiply the adress you want to write to by 2
add "dummy-bytes" for the odd locations


DATA @$20,$A1,0,$A2,0,$A3,0,$A4,0,$A5,0,$A6,0,$A7,0

marked red EEPROM location to write to multiplied by 2
marked green actual data to be written to EEPROM
marked blue "dummies" for odd locations

Step by step I'm getting closer to the migration from 16F to 18F

btw:
READ just works fine, so there is no modification of code required for the READ statements.

I hope this saves the forum members some time when trying to migrate from 16Fxxx to 18Fxxx

rgds

Or just upgrade to PBP 2.44. This upgrade takes care of this problem.

Quote:

---

Originally posted by Dave
Or just upgrade to PBP 2.44. This upgrade takes care of this problem.

---

PBP 2.44 does not solve the problem.

If you use the DATA statement as described in my first post in this thread you will get the result described there.

I have read somewhere that PBP 2.44 was supposed to take care of this problem but it does not really,
at least not on 18Fxx2 which require the use of MPASM.

Am I really the only one who is trying to migrate from 16F87x to 18Fxx2 and having problems?

The 18F series appear not to be the favorite PICs on this forum, I'm not getting much response to my questions.

@ Melanie

could you give any input to my threads?

I promise to gather all information / experience regarding the migration and I will post it as soon as the project has been successfully completed (if ever ;-) )

Well I just got done compiling a program for an 18F452 w/PBP2.44 and looking at eeprom locations w/MPLAB IDE 6.4 and I don't see any gaps in the eeprom memory used for data statements like you are talking about. I did however see this when compiling a program for an 18F1320.

@ Dave

could you give it a try on a 18F252 ?

I'm really interrested int your results.

The 18F252 seems to have lots of surprises for a developer.

rgds.

Have you asked Jeff at ME Labs about this problem? I running the 18F452 from using the 16F877 with PBP 2.42 and do not experience any problems like your talking about. Probably just a chip specific issue.

After commenting out a few PORTD & PORTE statements I was able to compile the same 18F452 program for an 18F252. After looking at the EEPROM memory with MPLAB 6.4 I do not see any gaps in the usage. The statements I use in the program to initially set the eeprom are as follows:
DATA @0,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,25
DATA@16,$42,$84,$A4,$83,$01,$24,$C3,$04,$02,$74,$A 3,$44,$C2,$82,$E3,$64,$D4,$43,$03,$81,$23,$14,$63, $94,$B4,$C4
DATA @42,$FD,$7D,$3D,$1D,$0D,$05,$85,$C5,$E5,$F5,$95
I hope this helps?
Dave Purola, N8NTA

Dave,

I have completely re-installed MPLAB (version 6.4.2)

here is what I get on the 252 using your code:

$0000 - $00 $00 $00 $00 $00 $19
$0008 - $42 $A4 $01 $C3 $02 $A3 $C2 $E3
$0010 - $D4 $03 $23 $63 $B4 $FD $3D $0D
$0018 - $85 $E5 $95

I found the following statement regarding the 18Fxxx issue on the melabs 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.

What am I doing wrong ? (apart from not using an EPIC programmer)

What application software are you using to view the eeprom memory locations? I am using MPLAB 6.40 after importing the hex file and selecting VIEW then EEPROM.

Dave Purola, N8NTA

I ask this because the statement: DATA @16,$42 should be placing a hex 42 at eeprom location 10 hex. Your printout shows hex 42 being located at hex 08. This would tell me that your program for reading the eeprom locations is referencing the locations as words and not bytes.

Dave Purola, N8NTA

Dave,

thanks for your time and patience!

It looks like we are getting closer.

When looking at the EEPROM using VIEW EEPROM in MPLAB everything looks fine.

MPLAB appears to take care of the addressing problem and corrects it for you.

When using any other tool and programming software you get the rubbish described in my previous posts.

There appears be a problem with the 18Fxx in conjunction with MPASM (3.50 and 3.60) they have "worked around"
in MPLAB and the EPIC programmer rather than fixing it in MPASM.

So if you can't use MPLAB / EPIC to program your devices (for what reason ever)
the only option appears to be the way described earlier (doubling the addresses and using "dummies" for the odd locations)

Having upgraded to the latest version of MicrocodeStudio and MicroCode Loader i have got rid of that problem.

But still:
If I look at the the EEPROM Data in the HEX-File using any other Tool than MPLAB or MCLoader (ie. IC-Prog) I see "garbage"
(I'm using different Programmers for different purposes, IC-Prog is just an example)

The strange thing is:

When I program a device using the Loader and read it back (ie. in IC-Prog) everything looks ok.

To me it looks like MPASM is handling / structuring EEPROM Data for the 18F in some different way than it does for the 16F devices.
when I compile exactly the same Code for a 16F876 the EEPROM Data is ok (even in IC-Prog).

So some newer programming tools appear to take care of the issue.

Does anyone have a final word of clarification ?

rgds.

What version of MPASM are you running?

Hi Melanie,

I have tried 3.50 and 3.60 both with the same result.

rgds

Thanks for the link
i am using PBP2.45

Toni