16F628 on-chip eeprom problem

Hello everyone,

I'm new to the group and I'd like to ask a question. I've recently
moved all my projects from 16F84 to 16F628 mcu's. Yesterday I've
tried to write data to the internal (on-chip) eeprom of 16F628 with
little (or no ;) sucess. Would anyone care to explain why the same
code works on 16F84 and 16F876/877 but not on 16F628? I used the
most common method:

EEPROM 0, 127 ' Store 127 into eeprom location 0
...
[code]
...
READ 0, W ' Put contents of memory location 0 into W
...
[code]
...
WRITE 0, W ' Put contents in W into eeprom location 0
...
END

And neither of the commands work! I've tried all locations from
0 - 11 for example and no luck. What am I doing wrong? Any help is
appreciated! Thanks in advance.

--
Sincerest regards,
YZ7REA Vladimir M Skrbic
4N7ATV Repeater Administrator
YU7GHZ Radio Club President

What version of PBP are you using?

I quote:
"Ver 2.32 had a Bug would not write to the EEPROM of 16F628..."

Read on http://list.picbasic.com/forum/messages/3064/3247.html
and/or search in this list.

It's 2.42, I think ;)

Try this,

B0 VAR BYTE
CHAR VAR BYTE

FOR B0 = 0 to 15
LOOKUP B0,["EEPROMS ARE COOL"],CHAR
WRITE B0, CHAR
NEXT B0

I'm using V2.43

Squibs

Squibcakes,

thanks for the reply. However that's exactly what I have done only it has
a for next loop... My 16F628's just
wan't store anything at locations
0 trough 11 if I use just:

WRITE location, value

EEPROM and DATA don't work either...


Vlad

Maybe if you posted the code you're using (to write to EEPROM), along with defines and port settings.

I'm probably stating the obvious here, but try erasing the Chip a few times in a row.. I have found that these chips get a bit flakey with numerous re-writes.

Is the supply voltage VDD high enough?

I'll post the code later today,as I'm at work right now. The supply voltage is
5.2V / 20A ;)

Vlad

PS I'll try to erase the chip several times and see where that takes me...

Posting what you're doing with your code and telling us what version PBP you're using may help us see what's going wrong. Additionally I'll draw your attention to...

http://www.picbasic.co.uk/forum/show...=&threadid=171

I've seen this problem now with several families of PIC's. As Microchip migrates products to micropower technology problems like this are starting to appear. If your application writes to EEPROM right at the start of your program, this can start executing WHILST STILL IN YOUR PROGRAMMER! You may need to adjust your program if this is happening in your case.

Melanie

Melanie,

Thanks for the reply. I've read the whole:

http://www.picbasic.co.uk/forum/show...=&threadid=171

thread and found it most informative. I'll post my code later this afternoon. Thanks a lot!!!

Vladimir

Vladimir, What type of programmer are you using to get the hex file into the PIC?. Are you making sure that the DATA CODE PROTECTION BIT (bit 8) is set to 1 in the configuration word. This bit maps to the WREN (EEPROM Write Enable) at location 9C hex. Check if this option is being set during the burn process as the configuration between F84 and an F628 are different. It may have been over looked. As for the code the only thing I see wrong is the missing brackets[ ] after the location. I use the 16F628 for my link controllers and use the EEPROM statement for storing the CWID characters. I hope this helps?

Dave Purola,

Hello everybody,

I'm sorry for not sending this earlier but my kid got sick yesterday and was chasing doctors all day long :(

Here's what I've done so far:

@ device WDT_ON, MCLR_OFF, HS_OSC, BOD_OFF, PWRT_ON, CPD_OFF, LVP_OFF

DEFINE OSC 20
CMCON = 7
VRCON = 0
TRISB = %11111111
TRISA = %00000000
OPTION_REG.7 = 0
Tx var portb.2
Rx var portb.1
C var word
T1 var word
T2 var word
T3 var word
T4 var word
T5 var word
Tmp_T var word
D var word
RT con 2110
P var byte
eeprom 0, [100]
eeprom 1, [350]
eeprom 3, [1981]
eeprom 5, [1860]
eeprom 7, [1860]
eeprom 9, [1860]
eeprom 11, [1860]
pause 500
init:
read 0, Period
read 1, D
read 3, T1
read 5, T2
read 7, T3
read 9, T4
read 11, T5
if portb.3 = 1 then main
SEROUT2 tx,16780,["ENTER 5-DIGIT VALUE",13,10]
get_c:
C = 0
SERIN2 rx,16780,[dec5 C]
If C = 0 Then get_c
SEROUT2 tx,16780,["C ",dec C," ACCEPTED, THANK YOU!",13,10]
gosub convert
SEROUT2 tx,16780,["T1= ",dec T1,13,10]
SEROUT2 tx,16780,["T2= ",dec T2,13,10]
SEROUT2 tx,16780,["T3= ",dec T3,13,10]
SEROUT2 tx,16780,["T4= ",dec T4,13,10]
SEROUT2 tx,16780,["T5= ",dec T5,13,10]
get_p:
SEROUT2 tx,16780,["D (xxx)?",13,10]
P = 0
SERIN2 rx,16780,[dec3 P]
If P = 0 Then get_p
SEROUT2 tx,16780,["P SET TO: ",dec P,", THANK YOU!",13,10]
get_d:
SEROUT2 tx,16780,["D (xxxx)?",13,10]
D = 0
SERIN2 rx,16780,[dec4 D]
If D = 0 Then get_d
SEROUT2 tx,16780,["D SET TO: ",dec D,", THANK YOU!",13,10]
write 0, P
write 1, D
write 3, T1
write 5, T2
write 7, T3
write 9, T4
write 11, T5
pause 500
main:
'...
'[code]
'..
GOTO main
convert:
'...
'[converts each digit from C to 4-digit word sized value]
'[i.e 1 = 1234, 2 = 5678, 3 = 9999 etc.]
'...
END

I guess Dave's remark regarding CPD stands... Thanks Dave. Everyone please take a look at this piece of code and tell me if you see anything wrong with it?

PS I use version 2.42

Sincerest regards,
--
YZ7REA Vladimir M Skrbic
4N7ATV Repeater Administrator
YU7GHZ Radio Club President

You're losing the plot before you start Vladimir...

eeprom 0, [100]
eeprom 1, [350]
eeprom 3, [1981]
eeprom 5, [1860]
eeprom 7, [1860]
eeprom 9, [1860]
eeprom 11, [1860]

As I replied to you earlier in the Private Message you can only store BYTES at a time in EEPROM. That's values 0-255 Decimal. At EEPROM address 1, you are trying to store 350, it's not going to happen. Pretend 350 is a 16-bit word, you will store the lower 8-bits into address 1, and NOTHING into address 2 (it will remain unchanged with any previous contents intact). The same at address 3 - you will store the lower 8-bits of the 16-bit value 1981, and address 4 will remain untouched.

Later on, you are reading words like this...

read 5, T2

You are expecting to have a value of 1860, but you won't. T2 will be loaded with the value from EEPROM address 5 ONLY. EEPROM address 6, (which you are expecting to load into the highbyte of T2 will NOT be read). REMEMBER that EEPROM operations work on ONE BYTE ONLY - Not Words - BYTES!

For example, let's take T2...

Initially you want to store 1860 (%0000011101000100) into locations 5 and 6, lowbyte into 5, and highbyte into 6. Do it like this...

DATA @5,%01000100
DATA %00000111

I used binary notation specifically to show you how to save a word constant (you can use the EEPROM command rather than DATA if you wish and of course you need not use Binary like I did for this explaination, you can use HEX or Decimals too).

Later on, when loading T2 do this (same technique when writing to EEPROM)...

read 5,T2.Lowbyte
read 6,T2.Highbyte

Remember BYTE AT A TIME. If you want WORDS you have to construct them out of two bytes - it will NOT be done automatically for you.

Melanie

Mel,

Thanks for the info. Yes I am aware that
some of my variables use WORDS, however I was under the impression that
PBP splits WORDS into two BYTE sized
values and stores them at two consecutive addresses. Oviously I was wrong. I'll do it the Mel way from now on ;) Thanks Melanie!

PS will let you know how it works...

Sincerest regards,
--
YZ7REA Vladimir M Skrbic
4N7ATV Repeater Administrator
YU7GHz Radio Club President

You CAN store WORDS as CONSTANTS, but you have to delfine them... to my previous example storing 1860 at locations 5 and 6...

DATA @5,%01000100
DATA %00000111

can (according to the manual) also be written as...

DATA @5, WORD 1860

although personally I always use my original method.

However, you still need two individual byte operations to READ and WRITE.

Melanie

As Melanie has mentioned so many times in the past, Please send a code snipit of where you might think the problem is. It wasn't untill the last 3 reply's to this thread that the problem was uncovered only after a code snipit was revealed. Thank you.

Well,

to conclude this thread, I would have to
say thank you everyone, especially you
Mel! I've made all the necessary changes
to my code (as Melanie suggested) and
it worked like a charm! I had a few minor
bugs in the code as well but I've managed
to sort 'em out. I appreciate your help...

Sincerest regards,
--
YZ7REA Vladimir M Skrbic
4N7ATV Repeater Administrator
YU7GHZ Radio Club President