"Write" with 16F676

I'm trying to get "Write" to EEPROM working with a 16F676 but nothing get's written. Can anyone give me a suggestion?

Thanks
Joe

http://mysite.verizon.net/jdrocci/

I haven't got one here to confirm, but I would assume it'll be the same way as any other PIC with normal on-board EEPROM...

WRITE Address,Mybyte

where 'Address' is any value between 0 and 127 for this PIC, and MyByte is a normal byte variable.

It's an easy mistake to get the Address and MyByte transposed just make sure you're not doing... WRITE MyByte,Address

Melanie

Melanie,
Thanks for the reply.
I checked the syntax several times. It sems like when I wrte the byte it stays in memory until power is removed, then it reverts to the unprogrammed value.

Joe

Three things Joe...

1. Have you tried another memory location? You may have a dud one - it's not unheard of.

2. Try something like this...

Data @5,10

Mybyte var Byte
Start:
Read 5,Mybyte
MyByte=MyByte*10
Write 5,Mybyte
Loop:
Pause 1000
Goto Loop

We first preset a value into memory address 5. We then Read it, modify it, and write it back out, then wait for you to power-off.

a. Burn the PIC
b. Read the EEPROM Memory contents back confirming your PIC's EEPROM has 10 burned into address 5.
c. Run the program
d. Once you've run this little program, remove the PIC, put it back into your programmer and read back the EEPROM content. See if it has changed (should be 100) or still remains preset at 10.

3. What version of PBP are you using?

Melanie

Melanie,
Just tried it..No joy

Joe

Oops...forgot...I'm running 2.42

So what was the result... what did you have as the before and after memory location as read-back by the programmer?

No change

Ummm... my version 2.42 doesn't support the 16F676 - perhaps that's your problem.

Sorry...2.43

I'm kinda stuck at this point as I don't have a 16F676 to try it with myself... but I'll see what I can acquire in due course... OK - post permitting I'll have some in the next day or so (I was going to get some for a forthcoming project anyway) so I'll come back to you on this thread shortly (unless someone else nails this in the interim).

Melanie,
This might be interesting...EEPROM works, so it's not the part.

Actually I believe it IS the part. I've also tested a Theory and drawn a Conclusion and a work-around... so stick with this till the end...

I've now got 10 pieces of 16F676 with Batch 0340044.

I also have had several verify errors when programming then verifying or just reading back. This in itself is strange (all will be explained why later)...

If I program the EEPROM manually (not using the PBP Compiler but using the editing functions of my EEPROM programmer into a BLANK - erased - PIC) as so for the 1st 32 Memory locations...

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

and I just read it back... the 2nd line (addresses $10 thru $1F) which should be all FF's come back as expected.

Now, creating a PBP program so...

'
' EEPROM Preset Data
' ------------------
Data @0,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
'
' Variable Defines
' ----------------
CounterA var Byte
MyByte var Byte
'
' Actual Program Start
' --------------------
Start:
For CounterA=0 to 15
Read CounterA,MyByte
MyByte=MyByte+16
Write CounterA+16,MyByte
Next CounterA
Loop:
Pause 1000
Goto Loop

End

Programming an erased PIC and just simply reading it back, I already find EEPROM corrupted expecting to find addresses $10 thru $1F as all $FF, instead I find addresses $10 with contents $10 and address $11 with contents $11 - as if my program has been ruuning for a few moments - but no, all I have done is programmed the PIC and read it straight back...

Now running the above program, and reading it back, you would expect addresses $10 thru $1F to contain...

10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F

instead they contain...

10 11 FF 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F

You will notice that address $12 is corrupt and not containing the expected data.

THEORY
======

It's almost as if the PIC has momentarily started to run for a few milliseconds whilst in the programmer, and being powered by the programmer before the programmer starts executing it's Read or Verify cycle.

Looking at the Datsheet I notice this is one of the new family of devices that really consumes micoamps, so to test the theory I've changed my test program...

'
' EEPROM Preset Data
' ------------------
Data @0,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
'
' Variable Defines
' ----------------
CounterA var Byte
MyByte var Byte
'
' Actual Program Start
' --------------------
Start:
Pause 2000
For CounterA=0 to 15
Read CounterA,MyByte
MyByte=MyByte+16
Write CounterA+16,MyByte
Next CounterA
Loop:
Pause 1000
Goto Loop

End

Notice I've put a BIG 2 second power-on delay before I start reading/writing to EEPROM...

Programming the PIC and immediately reading it back, whereas previously memory locations $10 and $11 (and sometimes $12) were corrupted, they are now $FF as they should be...

Running the program and then reading back the EEPROM contents the whole bank of $10 thru to $1F (including address $12) again is what it should be.

I've repeated this with all ten PIC's and have consistantly confirmed the EEPROM errors without the Pause, and no errors with the Pause.

CONCLUSION
=========

This PIC starts to run your program momentarily during the VERIFY or READ cycle of your programmer. That's where sometimes the VERIFY failed after the PIC's been programmed - the expected EEPROM contents had already changed!! Since I get two EEPROM locations written to (at 10mS each I believe) and a third is corrupted, this means that in my programmer at least this PIC is executing some 30mS worth of code.

Work-around... this PIC needs a Power-On delay at the start of your code BEFORE you do anything else... Pause 500 should suffice (probably overkill and Pause 100 would do it)... otherwise your brand-new programmed PIC that you've just taken out of your programmer may have actually already started executing your code adversely - so you put it in your board and it doesn't behave the way you expect with all kinds of internals corrupted by those few milliseconds of unexpected operation.

You don't expect PICs to start executing their code whilst sitting in your programmer so this is a real new one on me. Thanks to you Joe we've all learned something here - we should really stop being surprised at getting curve-balls thrown at us with these new PIC's.

What shall we call this for posterity... the "Joe effect" or the "Melanie effect"?

Melanie

Melanie,
Thanks for the prompt investigation!

I'll try your theory out on my application and let you know.

I really don't care what you call the effect...I'm just pleased that it wasn't me for a change and that a workaround might be available.

I'll be in touch

Thanks a heap

Joe

Just as a rider, above 'novelties' aside... in all other respects, as far as I can ascertain with my tests, PBP's READ, WRITE and DATA statements work they way they should with this PICs EEPROM.

I just finally wanted to add to this thread the PIC defines that I was using for my tests...

@ DEVICE pic16F676, INTRC_OSC_NOCLKOUT
' System Clock Options
@ DEVICE pic16F676, WDT_ON
' Watchdog Timer
@ DEVICE pic16F676, PWRT_ON
' Power-On Timer
@ DEVICE pic16F676, MCLR_OFF
' Master Clear Options (Internal)
@ DEVICE pic16F676, BOD_ON
' Brown-Out Detect
@ DEVICE pic16F676, CPD_OFF
' Data Memory Code Protect
@ DEVICE pic16F676, PROTECT_OFF
' Program Code Protection

Naturally if you've programmed for external oscillator or xtal, and external MCLR then the PIC hasn't the support circuitry attached to start and run... you'll probably only experience this phenomenon when the PIC is programmed for internal oscillator and MCLR.