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

[mytekcontrols]

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

[mister_e]

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?

[Melanie]

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.

[mister_e]

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

[Melanie]

Just Notepad as the editor.

[NavMicroSystems]

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.

[mytekcontrols]

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

[mister_e]

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.