Post by thread:[PIC]: EEPROM on f877

Hi, I'm having a wierd problem writing/reading to the EEPROM on the f877. I wanted to make two routines to write and read, and this is what I came up with: ;Writes the value in W to the address in 'temp' EEPROMWrite bsf STATUS,RP1 ;Switch to bank 2 movwf EEDATA bcf STATUS,RP1 ;Back to Bank 0 movf temp,w bsf STATUS,RP1 ;And back again to Bank2 movwf EEADR ;Set to Bank 3 bsf STATUS,RP0 ;Enable EEPROM Writing bsf EECON1,WREN movlw 0x55 movwf EECON2 movlw 0xAA movwf EECON2 ;Begin Write bsf EECON1,WR bcf EECON1,WREN ;Switch back to Bank 0 bcf STATUS,RP0 bcf STATUS,RP1 retlw 0x00 ;Reads the value at address W and puts it back in temp EEPROMRead ;Switch to bank 2 bsf STATUS,RP1 ;Move the address in W to EEADR movwf EEADR ;Switch to bank 3 bsf STATUS,RP0 ;Start the reading bsf EECON1, RD ;Back to Bank 2 bcf STATUS,RP0 movf EEDATA,w ;Switch bank to Bank 0 bcf STATUS,RP1 bcf STATUS,RP0 ;Move the contents of W to temp movwf temp retlw 0x00 Now what's wierd is that I called the Write fn twice, two different values, different addresses... and then called read on one of them. I read it fine... I then rewrote the code to read the other address (just one at atime), and I got the same thing?? So I'm not sure which fn. is working incorrectly. Anything seem to be wrong with my code? I know it's probably a bit inefficient, but I just want to get it working first. If you guys do'nt see anything wrong with this, I will look a bit closer at my fn to display the numbers on my LCd, but I'm pretty sure that's not the problem since it works for everything else. Thanx, Jai ---------------------------------------- This mail sent through http://www.mywaterloo.ca -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

These are the routines I use for EEPROM w/r. They're pretty similar to yours but notice that the write routine has a write completion test (possible problem ?). In some programs I use both EEPROM and FLASH so eepgd is explicitly set eewrite bank2 movwf eedata ;data from W bank0 movf eea,w ;address from bank0 RAM bank2 movwf eeadr bank3 bcf eecon1,eepgd ;select EEPROM memory bsf eecon1,wren ;initiate write movlw 0x55 movwf eecon2 movlw 0xaa movwf eecon2 bsf eecon1,wr bank0 btfss pir2,eeif ;wait for write completion goto $-1 bcf pir2,eeif return eeread bank0 movf eea,w ;address bank2 movwf eeadr bank3 bcf eecon1,eepgd bsf eecon1,rd bank2 movf eedata,w ;data bank0 return Pet hate - status,rpx instructions. They really clutter up code and can lead to incorrect bank switching. Try these macros, or Olin's bank selection routines bank0 macro bcf status,rp0 bcf status,rp1 bcf status,irp endm bank1 macro bsf status,rp0 bcf status,rp1 bcf status,irp endm bank2 macro bcf status,rp0 bsf status,rp1 bcf status,irp endm bank3 macro bsf status,rp0 bsf status,rp1 bcf status,irp endm -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

You may try this comparing to your program ;void weprom(char adr, char value) ;{ EEADR=adr; EEDATA=value; EEPGD = 0; WREN = 1; GIE=0; EECON2 = 0x55; EECON2=0xAA; WR=1; GIE=1; weprom: BCF 0x03,RP0 BCF 0x03,RP1 MOVWF value ;save parameters only... not important for you MOVF adr_2,W BSF 0x03,RP1 MOVWF EEADR BCF 0x03,RP1 MOVF value,W BSF 0x03,RP1 MOVWF EEDATA BSF 0x03,RP0 BCF 0x18C,EEPGD BSF 0x18C,WREN BCF 0x0B,GIE MOVLW .85 MOVWF EECON2 MOVLW .170 MOVWF EECON2 BSF 0x18C,WR BSF 0x0B,GIE ; while (WR); m039 BSF 0x03,RP0 BSF 0x03,RP1 BTFSC 0x18C,WR GOTO m039 BSF 0x03,RP0 ;WREN=0; BSF 0x03,RP1 BCF 0x18C,WREN ;} RETURN ;char leprom (char adr) ;{ EEADR=adr; EEPGD=0; RD=1; return EEDATA; } leprom BCF 0x03,RP0 BCF 0x03,RP1 MOVWF adr :save parameters as above MOVF adr,W BSF 0x03,RP1 MOVWF EEADR BSF 0x03,RP0 BCF 0x18C,EEPGD BSF 0x18C,RD BCF 0x03,RP0 MOVF EEDATA,W RETURN It's written in C and not very optimized. Hope it helps you a little. Igor {Original Message removed}

Fixed! you mentioned test for write completion, so I stuck one in there (except I tested the WR bit). I guess that was the problem... and the bankx macros are a good idea, I will use them! Thanks. Quoting Jinx <spam_OUTjoecolquittTakeThisOuTCLEAR.NET.NZ>: {Quote hidden}> These are the routines I use for EEPROM w/r. They're pretty > similar to yours but notice that the write routine has a write > completion test (possible problem ?). In some programs I use > both EEPROM and FLASH so eepgd is explicitly set > > eewrite > > bank2 > movwf eedata ;data from W > > bank0 > movf eea,w ;address from bank0 RAM > bank2 > movwf eeadr > > bank3 > bcf eecon1,eepgd ;select EEPROM memory > bsf eecon1,wren ;initiate write > movlw 0x55 > movwf eecon2 > movlw 0xaa > movwf eecon2 > bsf eecon1,wr > > bank0 > btfss pir2,eeif ;wait for write completion > goto $-1 > bcf pir2,eeif > return > > eeread > > bank0 > movf eea,w ;address > bank2 > movwf eeadr > bank3 > bcf eecon1,eepgd > bsf eecon1,rd > bank2 > movf eedata,w ;data > bank0 > return > > Pet hate - status,rpx instructions. They really clutter up code and > can lead to incorrect bank switching. Try these macros, or Olin's > bank selection routines > > bank0 macro > bcf status,rp0 > bcf status,rp1 > bcf status,irp > endm > > bank1 macro > bsf status,rp0 > bcf status,rp1 > bcf status,irp > endm > > bank2 macro > bcf status,rp0 > bsf status,rp1 > bcf status,irp > endm > > bank3 macro > bsf status,rp0 > bsf status,rp1 > bcf status,irp > endm > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > ---------------------------------------- This mail sent through http://www.mywaterloo.ca -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> and the bankx > macros are a good idea, I will use them! That's certainly better than doing BSF/BCF on RP0/RP1, but still leaves you open to errors of manually picking the wrong bank. You could make a macro that takes a RAM address and sets the banks accordingly. After all, the bank is just (adr >> 7). Now you can reliably set the bank without having to know which bank, but writing two BSF/BCF instructions in front of every RAM reference is wasteful. You could use an assembler variable to keep track of the current RAM bank, and only generate the BSF/BCF instructions that are needed. You could even avoid setting RP1 on processors that only have two or less banks, or emit nothing at all on processors that have only one bank. You could do all that, but you could also download a tested version of this macro for free. See my DBANKIF and related macros in STD.INS.ASPIC at http://www.embedinc.com/pic. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Olin, you wrote: >You could use an assembler variable to keep >track of the current RAM bank, and only generate the BSF/BCF instructions >that are needed. Do you know such macroassembler that is able to recognize labels, jump and call instructions to be able to keep a valid value in a variable you suggested? Optimalisation is the most difficult job when you try to write any compilator. To build a tree of a program isn't trivial. I would have been satisfied by a macroassembler that is able to do nontrivial string operations with parameters sending to macro. Do you know any? Regards Igor -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu>

> Do you know such macroassembler that is able to recognize labels, jump and > call instructions to be able to keep a valid value in a variable you > suggested? Optimalisation is the most difficult job when you try to write > any compilator. To build a tree of a program isn't trivial. MPASM certainly can't do that. The scheme I talked about is not fully automatic. I have the UNBANK macro which invalidates all bank assumptions. It is usually used at labels where execution can come from more than one point. At other places like subroutine entries and call points I already use macros that automatically do an UNBANK. > I would have been satisfied by a macroassembler that is able to do > nontrivial string operations with parameters sending to macro. Do you know > any? Microsoft MASM is the best assembler I've ever used, and it can do what you ask but is only for the Intel x86 processors. Unfortunately MPASM is pretty stupid in its handling of macro arguments. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestKILLspammitvma.mit.edu>

Olin Lathrop <.....olin_piclistKILLspam.....EMBEDINC.COM> wrote: > > Do you know such macroassembler that is able to recognize labels, > > jump and call instructions to be able to keep a valid value in a > > variable you suggested? Optimalisation is the most difficult job > > when you try to write any compilator. To build a tree of a program > > isn't trivial. > > MPASM certainly can't do that. The scheme I talked about is not > fully automatic. I have the UNBANK macro which invalidates all bank > assumptions. It is usually used at labels where execution can come > from more than one point. At other places like subroutine entries > and call points I already use macros that automatically do an UNBANK. > > > I would have been satisfied by a macroassembler that is able to do > > nontrivial string operations with parameters sending to macro. Do > > you know any? > > Microsoft MASM is the best assembler I've ever used, and it can do > what you ask but is only for the Intel x86 processors. Unfortunately > MPASM is pretty stupid in its handling of macro arguments. Assembly language is pretty simple to preprocess with Perl (or any other scripting language, for that matter), and this allows you to add fairly arbitrary macro-like capabilities. For example, I wrote a preprocessor that implements flow control commands (if/else/endif, loops, etc.) for the ADSP-21xx series of DSPs. This pretty much eliminates having to manually create labels within subroutines, avoiding the hassle of making up non-conflicting names. When I started working with PICs, I extended it to support them as well. After fiddling around with Olin's DBANKIF/UNBANK macros, I wrote a second preprocessor that inserts them automatically -- you just need to "declare" the symbols that are in banked RAM and it finds them wherever they're subsequently used. Together, these make the source code much more readable and easier to work with. Of course, this makes the toolchain rather complicated, involving my two preprocessors, Olin's "prepic" processor, Olin's macros and then the Microchip assembler and linker. I use Makefiles and the command- line tools, so I really don't need to worry about it once it's set up the first time. -- Dave Tweed -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu>