Searching \ for '[PIC] odd EE on 18F452' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=18F
Search entire site for: 'odd EE on 18F452'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] odd EE on 18F452'
2005\03\16@202553 by Roland

flavicon
face
Hi

I've got a really odd problem with the onboard EE memory of the 18F452.

I write some values to the EE during programming.
Immediately after programming, the program works OK, and is able to read
and write to internal EE, correctly.
If I do programmer READ, everything is there. Good.

If I dis-connect power, and re-apply, the program reads all EE values as 0x00.
If I now do a programmer READ, it's all there.
But!.. now as the chip re-sets, the program works correctly again

And! if I again dis-connect power, and re-apply, the program AGAIN reads
all EE values as 0x00.

So what looks like is happening is;?
On programming, the EE values are all put in OK
After a power down, the EE values 'leak'
Doing a programmer READ 'refreshes' the values

Any pointers anyone? My entire set-up has not changed since using the F877.
...I've just tried the exercise with a F877 now, and it works fine, ie
'remembers', but I've got 6 F452's that are acting up. So it looks like the
programmer?

I can't find anything in the manual about any config/var that would
dis-allow internal reads from the EE, or any powering down issue that would
cause this.



Regards
Roland Jollivet

2005\03\17@021808 by Jinx

face picon face

> So what looks like is happening is;?
> On programming, the EE values are all put in OK

Sounds like they probably are

> After a power down, the EE values 'leak'

Very very very unlikely

> Doing a programmer READ 'refreshes' the values

WRITE initiates a hardware sequence that READ doesn't. READ
cannot alter EE at all

> Any pointers anyone?

> I've got 6 F452's that are acting up. So it looks like the programmer?

Or the code ? Can you post some please. My guess is an address
pointer problem

2005\03\17@035509 by Jan-Erik Soderholm

face picon face
Roland wrote :

> I've got a really odd problem with the onboard EE memory of
> the 18F452.


Could you strip down your code to the smallest possible that
still shows this "error" (or whatever it is) and post that.

The chance is high that you will find the "bug" while
doing so, so maybe you never will have to post it... :-)

Jan-Erik.



2005\03\17@044636 by Alan B. Pearce

face picon face
>> So what looks like is happening is;?
>> On programming, the EE values are all put in OK
>
>Sounds like they probably are

I would agree.

>> After a power down, the EE values 'leak'
>
>Very very very unlikely

Again I agree.

>> Doing a programmer READ 'refreshes' the values


No I suspect this fixes the bit of code that you are missing by resetting
bits that come up in a different state after power up.

what are you doing with the various bits in the EECON1 register?
Specifically the bits that swap between data, program and configuration
memory?

2005\03\17@103358 by Roland

flavicon
face

Bingo!

Gee thanks Alan, I owe you, a beer?

The code was ported from the F877, and I did'nt check, line by line, to see
if the Read n Write of the EE was the same. The all important line that was
missing was 'bcf  EECON1,CFGS,ACCESS'

I must say that working with the 18F452 has been a daunting task. The
increased number of SFR's and all their config bits is a real minefield.

The program works fine now, after inserting that line in the EE read and
write. Of course, my worry is always that some config bit might get altered
or a flag get set that sends the prog into a loop, especially one that
includes the wdt. I'm almost tempted to put a routine in, that in the dead
of night, at the stroke of twelve, does a watchdog timeout(hardware) to
reset everything to a known state.

Also, the problem, honestly, never came up over the last week that I've
been working on this. It was only on programming the six new chips that it
came up.

The last worries are the FREE and WRERR bits.
I see FREE defaults to 0 on power up, but I'd bcf FREE in initialising? only?

With WRERR, I presume the basic strategy is;
- on power up, check if WRERR is set
   -if so, goto 'Restore'
   -do a check of WRERR before every EE read or write. If error, goto restore


Restore - clear WRERR
       - do a read of default variables from rom out to EE
- probably re-boot here



Thanks again.

Roland


At 09:46 AM 17/03/2005 -0000, you wrote:
{Quote hidden}

>-

2005\03\17@111028 by Alan B. Pearce

face picon face
>Bingo!
>
>Gee thanks Alan, I owe you, a beer?

I haven't used any of the 18 series family yet, but it was obvious that the
programmer was doing something to the registers which then never changed
until power down.

>The code was ported from the F877, and I did'nt check, line by
>line, to see if the Read n Write of the EE was the same. The
>all important line that was missing was 'bcf  EECON1,CFGS,ACCESS'

You ay want to see what the migration document has to say. Haven't looked
myself, but you may find some other possible gotchas as well. I started off
thinking that there was a high address reg for the EEPROM that you were not
initialising, but it is done differently in the 18 series.

2005\03\17@111624 by Hulatt, Jon
picon face

> I must say that working with the 18F452 has been a daunting
> task. The increased number of SFR's and all their config bits
> is a real minefield.
>

It really does seem to me that the whole 18 series architecture really
is designed for a C compiler, and not for assembler programming. It's a
bit of a headache in assembler, as you've found.

2005\03\17@114752 by Jan-Erik Soderholm

face picon face
Hulatt, Jon wrote :

> > I must say that working with the 18F452 has been a daunting
> > task. The increased number of SFR's and all their config bits
> > is a real minefield.
> >
>
> It really does seem to me that the whole 18 series architecture really
> is designed for a C compiler, and not for assembler programming.
> It's a bit of a headache in assembler, as you've found.

I don't know...

C-compilers might like the PIC18's better then the PIC16's,
but so do I when using assembler. A lot of things are far easier
to do in assmembler in the PIC18's then in the PIC16's, IMHO.

Jan-Erik.



2005\03\17@133004 by olin_piclist

face picon face
Hulatt, Jon wrote:
> It really does seem to me that the whole 18 series architecture really
> is designed for a C compiler, and not for assembler programming. It's a
> bit of a headache in assembler, as you've found.

I assume you are comparing it to the PIC 16 architecture?  What do you find
difficult?  I personally think the PIC 18 is easier to program in assembler
than the PIC 16.  Program memory pages are gone, and RAM banking is
simplified.  The LATx registers eliminate the read-modify-write to port
problem.  Some of the perpherals are more complex, but I only see that when
they have more features.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...