Is There A Bug In Eeprom-Write()?

[jrmymllr 0]

Using the newest version of BoostC (which by the way is working great otherwise) on 18F86K22. I noticed something odd in a routine that I had working in HI-TECH. After some debugging, I figured out that when eeprom_write() is passed an address of 0x100, it writes to 0x00, and so on. So instead of passing it a variable containing the address, I did a test:

 

eeprom_write(0x100, 0x55);

eeprom_write(0x101, 0xAA);

 

Low and behold, EEPROM addresses 0x000 and 0x001 now contain 0x55 and 0xAA respectively. In eeprom.h, I see this:

 

#elif _PIC18

unsigned char eeprom_read( unsigned char address );

void eeprom_write( unsigned char address, unsigned char data );

#ifdef EEADRH

unsigned char eeprom_read( unsigned short address );

void eeprom_write( unsigned short address, unsigned char data );

#endif

 

 

However if I attempted to define EEADRH (which I shouldn't have to) it complains. So I printed a message right after " #ifdef EEADRH" to check if it's using the prototypes where "address" is a short int instead of char, and it is using the short int version.

 

What's going on here? Right after writing to 0x100, I check eeadr and eeadrh, and they are both zero.

[Reynard 0]

Hi,

 

There was some change for this problem but it may not have yet reached a release version.

The source file for eeprom.c may have been given out as a file. Do a quick search of the forum for it. I seem to have it in my goodies directory.

 

Better still write your own and do writes under interrupts. I do it for the 18F26K22 without any problems.

 

Cheers

 

Reynard

[jrmymllr 0]

Hi,

 

There was some change for this problem but it may not have yet reached a release version.

The source file for eeprom.c may have been given out as a file. Do a quick search of the forum for it. I seem to have it in my goodies directory.

 

Better still write your own and do writes under interrupts. I do it for the 18F26K22 without any problems.

 

Cheers

 

Reynard

 

No luck finding it in the forums.

 

I could write my own, but for now I've put it off hoping for a fix so I don't have to spend time on it.

[Reynard 0]

Hi,

 

Been searching around. I think it was the annoncement of 7.10 that gave me the latest source for eeprom.h in the goodies.

 

I looks like the eeprom.lib may not have been recompiled with the new source.

 

If I cut and paste the eeprom source into my main file I get the expected code using eeadrh.

 

Another good reason to write your own code. You have full control of what is going on.

 

Cheers

 

Reynard

[Reynard 0]

Something odd going on here.

 

The eeprom.c file has conditional compilation depending on whether EEARDH is defined.

You can't do this and also create a single library for pic18. Can you ?

 

Cheers

 

Reynard

[jrmymllr 0]

Something odd going on here.

 

The eeprom.c file has conditional compilation depending on whether EEARDH is defined.

You can't do this and also create a single library for pic18. Can you ?

 

Cheers

 

Reynard

 

It doesn't seem to me like you can, but this conditional statement you speak of is related to the problem I think, because it behaves as if the address parameter is only a char.

As for eeprom.c, I haven't been able to find this. I found eeprom.h, the .lib files, but no C source.

[Reynard 0]

Hi,

 

The source code is only available if you have the full or Pro version of SB.

There is a file called goodies.exe which you need to request a key from SB to extract the source code.

 

Maybe SB requires two libraries, one for 8 bit addressing and one for 16 bit addressing devices (PIC18).

You can't use function overloading and hope it picks the right one for you as you can pass an 8 bit address to a 16 bit device.

 

At a dozen lines of code for each read and write function just do it yourself.

 

Cheers

 

Reynard

[JorgeF 0]

Hi

 

In the source code for the eeprom lib, the read and write functions are overloaded, one version for "unsigend char" address and one for "unsigned short".

Its a bit of a long shot, but you can try an explicit type cast of your "address" when caling this functions.

Just to see if it makes any difference.

 

If not, then we have to conclude that the pic18 eeprom lib file is outdated, meaning it wasn't compiled from the latest sources (from goodies).

 

 

Best regards

Jorge

Edited December 7, 2012 by JorgeF

[jrmymllr 0]

Hi,

 

The source code is only available if you have the full or Pro version of SB.

There is a file called goodies.exe which you need to request a key from SB to extract the source code.

 

Maybe SB requires two libraries, one for 8 bit addressing and one for 16 bit addressing devices (PIC18).

You can't use function overloading and hope it picks the right one for you as you can pass an 8 bit address to a 16 bit device.

 

At a dozen lines of code for each read and write function just do it yourself.

 

Cheers

 

Reynard

 

I did not realize goodies is an executable, I assumed it is a directory and knew I didn't have that. So, I tried running it, and it says how I need a

license, etc. So it won't extract, however I have the full commercial license and the compiler says so when building.

 

EDIT: I just figured out I have to run preg.exe first just like I did for the compiler, but it says "The name/key you entered does not appear to be valid. Please try again." Confused now. I'm using the same key I did for the compiler.

 

 

 

Jorge I did try casting it yesterday, but that didn't work either.

Edited December 7, 2012 by jrmymllr

[JorgeF 0]

Hi

 

The key for "goodies" is not the same as for the compiler.

You have to mail sourceboost support and ask for the key to extract the goodies.

 

 

BTW:

You don't need to run "preg",

When you receive your key, just run goodies from the command line and feed it the key as a parameter.

 

 

Best regards

Jorge

Edited December 7, 2012 by JorgeF

[Pavel 0]

The eeprom.c file has conditional compilation depending on whether EEARDH is defined.

You can't do this and also create a single library for pic18. Can you ?

 

Yes you can. The library takes advantage of the function overloading. The lib file contains both functions: one that uses 8 bit address and another that uses the 16 bit one but the header file only declares one of those based on the EEARDH definition. This way all external to the library code can use only one of these functions.

 

Regards,

Pavel

[Reynard 0]

Hi Pavel,

 

I think you need to give us a working example of using a 16 bit eeprom address.

 

I cannot get it to work using eeprom.pic18.lib

The assembly code does not show eeadrh register.

 

I am building for the 18F86K22 which does contain the EEADRH definition.

 

Cheers

 

Reynard

[JorgeF 0]

Hi

 

If you open the projects "libc.pic16.__c" and "libc.pic18.__c" in the "libc" folder you will notice that they don't include the "eeprom", "adc", "oo" and "flash" modules.

My understanding is that the default libs don't have this functions included.

 

So, either we include this modules in the "libc....." projects and rebuild the libs or we include the source code directly on our projects.

Take your pick gentlemen.

 

 

This code

// target device is PIC18F8722
#include <system.h>
#include <eeprom.h>

unsigned short data_rd;
unsigned char data_wr;


void main(void)
{

unsigned short ptr;
unsigned char val = 255;

	while(1)
		{
		for(ptr=1023; ptr; ptr--)
			{
			data_rd = eeprom_read(ptr);
			eeprom_write(ptr, val);	
			val--;
			} // for(ptr=1023; ptr; ptr--)
		}	// while(1)
}  // void main(void)

compiles and links without issues after rebuilding "libc.pic18" with "libc\eeprom\eeprom.c" included.

 

 

 

Best regards

Jorge

Edited December 11, 2012 by JorgeF

[Reynard 0]

Hi Jorge,

 

Yes there are several solutions to the problem, the best one is write your own.

 

Not everyone has access to the souce files to do a rebuild.

The eeprom functions are supplied in their own libraries.

The product should work out of the box without having to rebuild libraries.

 

Cheers

 

Reynard

[JorgeF 0]

Hi

 

I see your point Reynard, but don't forget that we are talking about some extras that are not part of the base system.

For some reason they are called "goodies" and only available to licensed users.

The "goodies" are distributed in source code form, including them in a lib is optional.

As I see it is excatly the same thing as collecting our own personal toolkit in the form of a lib or not. In teh end is just each ones personal way of working.

 

 

@jrmymllr

Do you alredy have your "goodies" licence?

When you do, if you need I can give you a hint or two in rebuilding the libs.

 

 

BTW:

I found the best instructions on building libs in the NOVO RTOS manual, were its explained how to adjust the RTOS to each project specific needs.

Follow the steps and it works like a breeze.

 

 

Best regards

Jorge

Edited December 11, 2012 by JorgeF

[Reynard 0]

Hi Jorge,

 

The eeprom libraries are supllied as part of the core system fully compiled.

 

A seasoned programmer like yourself has no problems diving in and getting on with it but a newbie is left flapping in the breeze beating his head off a wall.

 

Whether you buy the lite or pro version you should not need to recompile the libraries before you start.

 

I use Novo in many build versions and as you say is very simple and works well.

 

Cheers

 

Reynard

[jrmymllr 0]

Hi

 

I see your point Reynard, but don't forget that we are talking about some extras that are not part of the base system.

For some reason they are called "goodies" and only available to licensed users.

The "goodies" are distributed in source code form, including them in a lib is optional.

As I see it is excatly the same thing as collecting our own personal toolkit in the form of a lib or not. In teh end is just each ones personal way of working.

 

 

@jrmymllr

Do you alredy have your "goodies" licence?

When you do, if you need I can give you a hint or two in rebuilding the libs.

 

 

BTW:

I found the best instructions on building libs in the NOVO RTOS manual, were its explained how to adjust the RTOS to each project specific needs.

Follow the steps and it works like a breeze.

 

 

Best regards

Jorge

 

I don't have that license yet. I was hoping Pavel or Dave would jump in soon and clarify this a bit. I could write my own, but have pushed off this issue as it's not holding me up right now. I'm actually doing wear-leveling of a small block of data, so for now I simply assume the EEPROM is only 256 bytes instead of 1024 on the prototype units.

[Reynard 0]

The EEADRH is reset on POR but put it in your code for correctness.

 

It can be difficult for compiler vendors to keep up with all Microchips new devices but they are getting there.

This eeprom issue needs to be fixed once and for all to keep user confidence in the product.

 

I have thought about moving eeprom data around the block myself before I hit the 100k mark.

To write to eeprom at any power down could mean a long supply hold up time if there is a lot to write.

 

Gone are the good old days of ferrite core memory. Ahhh! The days when computers were also room heaters.

 

Good luck with your project.

 

Cheers

 

Reynard

[jrmymllr 0]

The EEADRH is reset on POR but put it in your code for correctness.

 

It can be difficult for compiler vendors to keep up with all Microchips new devices but they are getting there.

This eeprom issue needs to be fixed once and for all to keep user confidence in the product.

 

I have thought about moving eeprom data around the block myself before I hit the 100k mark.

To write to eeprom at any power down could mean a long supply hold up time if there is a lot to write.

 

Gone are the good old days of ferrite core memory. Ahhh! The days when computers were also room heaters.

 

Good luck with your project.

 

Cheers

 

Reynard

 

I'm paranoid about wearing things out, so I always do this if data will change more often.

 

I have used the "write at power down" by using LVD interrupt. It seems to be hit or miss. It's a great concept, but the reliability of that implementation takes some time to validate.

[JorgeF 0]

Hi

 

I don't have that license yet. I was hoping Pavel or Dave would jump in soon and clarify this a bit.

Don't know if something changed meanwhile.

But I had to send a mail asking for it (goodies licence key) to Sourceboost support, after receiving my BoostC licence.

In that mail I sent my BoostC licence key and register name for them to verify that I was entitled to the "goodies" (think I forwarded the original BoostC licence e-mail).

 

 

 

@Reynard:

I guess you are right, I saw nothing in the docs stating any kind of special conditions to access the "eeprom", "adc", "oo" and "flash" library functions.

I convicted myself they were some kind of extra just because they were not available when I downloaded the Sourceboost package for testing before buying my own Pro licence. And latter find them as part of "goodies" that I thought to be NOVO related only.

 

 

Best regards

Jorge

[Reynard 0]

Microchip do some nice serial eeprom chips with 1M erase cycles.

They are paged at 16 bytes so you can dump out 16 bytes in the same time as 2 bytes on a PIC.

 

Cheers

 

Reynard

[Pavel 0]

...I was hoping Pavel or Dave would jump in soon and clarify this a bit...

 

We investigated this issue and it looks like there is some build problem in the eeprom library included into the 7.10 release If the same library is re-built it works as expected. I will attach an updated library from the coming 7.11 release to this thread later today when I get access to my development system.

 

To call eeprom_write with 16 bit address just make the call with 16 bit long first call argument like:

 

#include <system.h>
#include <eeprom.h>
...
//this will call eeprom_write( unsigned short, unsigned char )
eeprom_write(0x100, 0x55);
//this will call eeprom_write( unsigned char, unsigned char )
eeprom_write(0x10, 0xAA);

 

Regards,

Pavel

[Reynard 0]

Thanks Pavel,

 

We all look forward to the 7.11 release to play with over Christmas.

 

Cheers

 

Reynard

[Pavel 0]

We decided to split the eeprom library for PIC18 into 2: one that uses 8 bit addressing and another that uses 16. Both will be part of 7.11 release and are attached to this post. The header file hasn't changed.

 

Regards,

Pavel

eeprom.zip