Post by thread:[PIC] odd EE on 18F452

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

> 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

>> 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?

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}>>> 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? > >-

>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.

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.

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