Post by thread:[PIC] EEPROM data read problem for 16f819

Hi folks, I've reached the end of my tether on a problem and I'm hoping someone can help! I've written a program for a 16f818 which, amongst other things, writes an 8-bit word to the PIC chip's data EEPROM and reads it back to be displayed on an LCD. The code is straight out of the Microchip notes and works fine and consistently. I have now upgraded the project to a 16f819 to give me more program and data memory. The changes to the code are just the header. However, when I write a known value, it's incorrect when read back. Furthermore, it's not consistent (it stays consistent for a few power ups and then changes). I have tried several different chips (DIL and SMD) and they all have a problem. I'm using MPLAB V6.30 and Forest's serial programmer with the latest firmware. I've spent ages on this and *any* help would be great. Thanks, Steve Parker

The problem is that you have not determined whether you are writing incorrectly, reading incorrectly, or both. Using your new routine, write a few bytes to the EEPROM. Then get the programmer for the F819 and see if it was written correctly. Start there, then work out. Especially- make SURE the bank switches are set correctly and make sure you have NO interrupts when flashing the byte. --Bob Steve Parker wrote: {Quote hidden}>Hi folks, > >I've reached the end of my tether on a problem and I'm hoping someone can >help! > >I've written a program for a 16f818 which, amongst other things, writes an >8-bit word to the PIC chip's data EEPROM and reads it back to be displayed >on an LCD. The code is straight out of the Microchip notes and works fine >and consistently. > >I have now upgraded the project to a 16f819 to give me more program and data >memory. The changes to the code are just the header. However, when I write a >known value, it's incorrect when read back. Furthermore, it's not consistent >(it stays consistent for a few power ups and then changes). I have tried >several different chips (DIL and SMD) and they all have a problem. > >I'm using MPLAB V6.30 and Forest's serial programmer with the latest >firmware. > >I've spent ages on this and *any* help would be great. > >Thanks, > >Steve Parker > > > > -- Note: To protect our network, attachments must be sent to spam_OUTattachTakeThisOuTengineer.cotse.net . 1-866-263-5745 Tollfree

> I'm using MPLAB V6.30 and Forest's serial programmer with the latest > firmware. A bit of code to look at would be nice ;-) Have you checked the errata to see if anything you're doing affects proper EEPROM operation ? http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2045 Specifically http://ww1.microchip.com/downloads/en/DeviceDoc/80159e.pdf http://ww1.microchip.com/downloads/en/DeviceDoc/80212b.pdf Only INTOSC and PORTB appear here but there could be an indirect link (for example I'm sure there's a funny connection between PortA analogue and PortB on the 452 that's not documented)

Steve Parker wrote: > I've written a program for a 16f818 ...snip... > I have now upgraded the project to a 16f819 I would strongly suspect a banking problem, probably involving a register you're using to hold the EEPROM data byte while switching to/from the banks with the EEPROM SFRs. Much of the 16F818's RAM is shadowed in all four banks, but generally only the top 16 bytes of each bank is shadowed on the '819. Jason Harper

I posted a problem recently where my code for writing and reading to and from the PIC EEPROM memory stopped working when I updated from a 16f818 to a 16f819 device. The problem was found to be because the program memory is not shadowed in the 16f819 like it is in the 16f818 and therefore you have to be explicit about the 'banks' throughout the code. This is something to note in general, always check your banks! I would like to thank those who replied (Bob Axtell, Jason Harper and Jinx). You guys know your stuff, I'm very grateful! Regards, Steve

Steve Parker wrote: >I posted a problem recently where my code for writing and reading to and >from the PIC EEPROM memory stopped working when I updated from a 16f818 to a >16f819 device. The problem was found to be because the program memory is not >shadowed in the 16f819 like it is in the 16f818 and therefore you have to be >explicit about the 'banks' throughout the code. This is something to note >in general, always check your banks! > >I would like to thank those who replied (Bob Axtell, Jason Harper and Jinx). >You guys know your stuff, I'm very grateful! Regards, Steve > > > Hi Steve- Yikes! Who would suspected such major differences in parts that share the same datasheet! David

On Sat, 15 Jan 2005 04:53:07 -0800, David P Harris wrote: <snip> >Hi Steve- >Yikes! Who would suspected such major differences in parts that share >the same datasheet! >David It depends on what the difference between the parts really is. For example, if the '819 has twice the data RAM as the '818 does, it would need to use banking while the smaller part wouldn't. The difference that caught me by surprise was that not all of the 16F87x parts have the top 16 bytes as unbanked RAM. Some do, some don't. Regards, Bob

> Yikes! Who would suspected such major differences in parts > that share the same datasheet! > David Major differences ? In what way ? Shouldn't you care about banking in *any* PIC ? (Or rather, you should/could let the assembler take care of the banking for you...) Best Regards, Jan-Erik

>Major differences ? In what way ? >Shouldn't you care about banking in *any* PIC ? >(Or rather, you should/could let the assembler take >care of the banking for you...) Especially if you use macros like those Olin provides - then you code for the complex version, and the macro stops code generation where not needed.