PIC vs EEPROM

I've a strange problem writing internal EEPROM of a 16F628. The code work fine in MPLAB Simulator but not in my circuit. I write data (in EEDATA) from INDF pointed mem locations. The write work fine if I load WREG directly with "movlw" i.e movlw H'AA' then moving it to EEDATA (read back pic eeprom get 'AA') but if i load the EEDATA reg from W after a movf INDF, W then eeprom get all zeroes in any location accesed for write. I'm sure that W is loaded correctly because the value writed is also displayed on a LCD MODULE.

I hope someone can show me the eror of my ways.

Code Chunk:

movlw ROM_NO WRITE_EEPROM_ROM_NO movwf FSR ; W = address of ROM_NO (first byte) movf INDF, W ; Load W with the byte pointed by FSR BANK1 ; MACRO to switch in Bank1 ;movlw H'AA' ; TEST.. WITH THIS DIRECT LOAD WORK!! movwf EEDATA clrf EEADR ; Write at address 00h BSF EECON1, WREN ; Enable write MOVLW H'55' ; MOVWF EECON2 ; Write 55h MOVLW H'AA' MOVWF EECON2 ; Write AAh BSF EECON1, WR ; Set WR bit WRITE_EEPROM_WAIT

btfsc EECON1, WR ; Wait for wrinting goto WRITE_EEPROM_WAIT ... ...

Thanx Alex

Reply to
alexbnNG
Loading thread data ...

I guess that the code piece that is marked as "required sequence" in the PIC documentation is - um - required for the PIC to work correctly.

See datasheet, chapter 13.3 and 13.4.

Reply to
Matthias Melcher

the "required sequnce" is present, as you can see...

Reply to
alexbnNG

The errata for the 628 is extensive. Have you looked at page 16 of it?

Jon

Reply to
Jonathan Kirwan

Yes Jon I've looked it...

my problem is that: using a "movlw H'BB'" then a movwf to EEDATA the eeprom write take place. using a movf MY_DATA, w then a movwf to EEDATA the eeprom write take place but the value stored is always H'00'.

Alex

Reply to
alexbnNG

bcf INTCON, GIE is missing. I kow, I know, that's not logical, particularly if you don't use interrupts anyways, but I found that not everything about PIC's is logical and it is documentd as 'required'. Maybe it needs the extra cycle between enabeling the write and actually writing.

Anyways, looking at the errata seems like a very good idea.

I can't see anything else wrong with your code, assuming ROM_NO is correct.

Good luck,

Matt

schrieb im Newsbeitrag news: snipped-for-privacy@z14g2000cwz.googlegroups.com...

Reply to
Matthias Melcher

I didn't look at your code and compare it with the errata, only noticed the existence of the errata on the subject and figured on pointing it out. If I had some 628's handy here, I'd write some code and try it out and comment more fully. But I don't. What I've got are many other versions of PICs, but not those.

And yes, I've had problems with EEPROMs on PICs, called Microchip about it, got a recognition of the problem and a resolution in a few days, along with a new errata in two weeks that documented it. So good service, yet real problems with EEPROM, too.

Have you tried calling them? My past experience has been good on that score.

Jon

Reply to
Jonathan Kirwan

Use the exact sequence given by the errata note for reading, writing, and verifying. Also, you aren't setting the bank back to 0 at the end of the routine.

Write a program that tests only that routine, with no others assembled in, and see what happens. Make sure your input values aren't getting clobbered, and the FSR is getting set to the right thing.

--
Regards,
  Bob Monsen
Reply to
Bob Monsen

I've found the problem!!! My program it's ok, since three days (night :(( )! I was sure that my programmer was able to read correctly PIC eeprom but somthing don't work... The locations that the programmer report as ZEROES are correctly writed from my write_routine (the read_eeprom routine on PIC get correct data). The programmer I use is PIC-PG2 from Olimex

formatting link
I don't undestand why this error reading eeprom locations.... The strange is tha location writed directly with the programmer are correctly read back but those write by PIC are not. Any Someone has had the same problem with this programmer?

Alex

Reply to
alexbnNG

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.