Post by thread:RAM/EEPROM

Client has a 16F887 in a product,and they do limited runs of 20 or so at a time. Maybe one out of the batch shows problems that allude to that the ram locations are being corrupted, and perhaps even EEPROM locations. The value in the ram is loading a timer and so when its bad....the timer is way off. It loads from EEPROM, and so the code allows the user to check the value and its wrong. So what I am asking is.....has anyone seen issues where RAM locations get corrupted? The client can run it 9 or 10 times, works fine (power cycle) but then it fails...and the other boars being built run just fine. Bad chips? I find that hard to believe these days.

part 1 547 bytes content-type:TEXT/PLAIN; charset=iso-8859-1; format=flowed (decoded quoted-printable) On Mon, 16 Jun 2008, alan smith wrote: > Client has a 16F887 in a product,and they do limited runs of 20 or so at a time.� Maybe one out of the batch shows problems that allude to that the ram locations are being corrupted, and perhaps even EEPROM locations.� The value in the ram is loading a timer and so when its bad....the timer is way off.� It loads from EEPROM, and so the code allows the user to check the value and its wrong. Is the PIC protected from brownout? -- John W. Temples, III part 2 35 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit)

No...but, found the problem. Just goes to show what can get past you when moving from legacy code to new stuff. The history was this used to be in an 16F877, so they spun the board for the 887, and "added features" which translates to added code, and more variables. The original author used the cblock directive, but hardcoded some variables at the bottom end of the RAM, and as I added some additional variables it wrote over the top a couple of these. For those wondering how I saw this, because the compile didnt show this as an error, always review the listings, it shows up very clear there. So...isnt that how it goes? You post due to frustrations...and it shows itself right after. But as always.....thanks for listening. Client has new code this morning, so hopefully he can now ship :-) --- On Mon, 6/16/08, John Temples <spam_OUTpiclist3TakeThisOuTxargs.com> wrote: {Quote hidden}> From: John Temples <.....piclist3KILLspam@spam@xargs.com> > Subject: Re: [PIC] 16F887 and corrupted RAM/EEPROM > To: "Microcontroller discussion list - Public." <piclistKILLspammit.edu> > Date: Monday, June 16, 2008, 11:58 PM > On Mon, 16 Jun 2008, alan smith wrote: > > > Client has a 16F887 in a product,and they do limited > runs of 20 or so at a time. Maybe one out of the batch > shows problems that allude to that the ram locations are > being corrupted, and perhaps even EEPROM locations. The > value in the ram is loading a timer and so when its > bad....the timer is way off. It loads from EEPROM, and so > the code allows the user to check the value and its wrong. > > Is the PIC protected from brownout? > > -- > John W. Temples, III-

alan smith wrote: > The > original author used the cblock directive, but hardcoded some > variables at the bottom end of the RAM, and as I added some > additional variables it wrote over the top a couple of these. So anyone out there still wonder why you should always use RES to reserve RAM? ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

> because the compile didnt show this as an error,... Relocatabl mode and MPLINK had barfed about it... :-) :-) Best Regards, Jan-Erik. alan smith wrote: {Quote hidden}> No...but, found the problem. Just goes to show what can get past you when moving from legacy code to new stuff. The history was this used to be in an 16F877, so they spun the board for the 887, and "added features" which translates to added code, and more variables. The original author used the cblock directive, but hardcoded some variables at the bottom end of the RAM, and as I added some additional variables it wrote over the top a couple of these. For those wondering how I saw this, because the compile didnt show this as an error, always review the listings, it shows up very clear there. > > So...isnt that how it goes? You post due to frustrations...and it shows itself right after. > > But as always.....thanks for listening. Client has new code this morning, so hopefully he can now ship :-) > > > --- On Mon, 6/16/08, John Temples <.....piclist3KILLspam.....xargs.com> wrote: > >> From: John Temples <EraseMEpiclist3spam_OUTTakeThisOuTxargs.com> >> Subject: Re: [PIC] 16F887 and corrupted RAM/EEPROM >> To: "Microcontroller discussion list - Public." <piclistspam_OUTmit.edu> >> Date: Monday, June 16, 2008, 11:58 PM >> On Mon, 16 Jun 2008, alan smith wrote: >> >>> Client has a 16F887 in a product,and they do limited >> runs of 20 or so at a time. Maybe one out of the batch >> shows problems that allude to that the ram locations are >> being corrupted, and perhaps even EEPROM locations. The >> value in the ram is loading a timer and so when its >> bad....the timer is way off. It loads from EEPROM, and so >> the code allows the user to check the value and its wrong. >> >> Is the PIC protected from brownout? >> >> -- >> John W. Temples, III--

Now that this is solved...it points out that using RES and linkers does indeed catch certain problems like this. But its the old problem of fixing things that are not really broken..ie...it could be made better but works as it is (for the present at least). --- On Tue, 6/17/08, Alan B. Pearce <@spam@A.B.PearceKILLspamrl.ac.uk> wrote: {Quote hidden}> From: Alan B. Pearce <KILLspamA.B.PearceKILLspamrl.ac.uk> > Subject: Re: [PIC] 16F887 and corrupted RAM/EEPROM > To: "Microcontroller discussion list - Public." <RemoveMEpiclistTakeThisOuTmit.edu> > Date: Tuesday, June 17, 2008, 4:33 AM > >> It loads from EEPROM, and so the code allows the > user to check > >> the value and its wrong > > > >How does the data get in the EEPROM in the first place > ? Sounds > >more like feral s/w than bad chips > > I was thinking about uninitialized variables - again feral > software. > --

...I just pointed out that....guess we were thinking alike. I'm just considering going in and making these changes no charge, just to make it easier to support going forward. Like I have extra time to do this, but well worth while to do before it bites me or someone else again. --- On Tue, 6/17/08, Olin Lathrop <spamBeGoneolin_piclistspamBeGoneembedinc.com> wrote: {Quote hidden}> From: Olin Lathrop <TakeThisOuTolin_piclistEraseMEspam_OUTembedinc.com> > Subject: Re: [PIC] 16F887 and corrupted RAM/EEPROM > To: "Microcontroller discussion list - Public." <RemoveMEpiclistTakeThisOuTmit.edu> > Date: Tuesday, June 17, 2008, 6:38 AM > alan smith wrote: > > The > > original author used the cblock directive, but > hardcoded some > > variables at the bottom end of the RAM, and as I added > some > > additional variables it wrote over the top a couple of > these. > > So anyone out there still wonder why you should always use > RES to reserve > RAM? > > > ******************************************************************** > Embed Inc, Littleton Massachusetts, > http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. > --

> So anyone out there still wonder why you should always use RES to reserve RAM? Anyway, variable definitions should go to a single place not just here and there in the code which makes everything messy. If there were only one cblock then that kind of mistakes could have been eliminated. The linker script is however generally a good idea and even unavoidable if the source is separated into files - but even then a 'res' here and there is not a good practise. Tamas On Tue, Jun 17, 2008 at 2:38 PM, Olin Lathrop <olin_piclistEraseME.....embedinc.com> wrote: {Quote hidden}> alan smith wrote: > > The > > original author used the cblock directive, but hardcoded some > > variables at the bottom end of the RAM, and as I added some > > additional variables it wrote over the top a couple of these. > > So anyone out there still wonder why you should always use RES to reserve > RAM? > > > ******************************************************************** > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. > -

>So...isnt that how it goes? You post due to frustrations... >and it shows itself right after. > >But as always.....thanks for listening. Client has new code >this morning, so hopefully he can now ship :-) I hope you have changed it to relocatable code so you can follow Olins (and others) advice about how to allocate RAM space ... Otherwise you will get caught twice ...

Tamas Rudnai wrote: > Anyway, variable definitions should go to a single place not just here and > there in the code which makes everything messy. If there were only one > cblock then that kind of mistakes could have been eliminated. The linker > script is however generally a good idea and even unavoidable if the source > is separated into files - but even then a 'res' here and there is not a good > practise. I prefer to keep the RES together with each routine. That way I get both the variables and the code at the same time when I decide to include something, such as some standard LCD code or whatever. RES makes it realy easy to have variable allocations (RES) scattered around the code since MPLINK takes care of all addresses. If you realy need to see all your variable allocations in one place, look in the MAP file... Jan-Erik.

Tamas Rudnai wrote: > The linker script is however generally a good idea and > even unavoidable if the source is separated into files - but even > then a 'res' here and there is not a good practise. Not at all. This is old absolute mode thinking. RES has the extra checks such that it is perfectly fine, even desirable, to have variable definitions in different places. Regardless of how many places variables are defined with RES, they are still all guaranteed not to overlap and not to overflow a linker memory region. Local variables of a module should be defined in that module. Putting all local variable definitions in a central place is really bad programming practise. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

Olin Lathrop wrote: > alan smith wrote: >> The >> original author used the cblock directive, but hardcoded some >> variables at the bottom end of the RAM, and as I added some >> additional variables it wrote over the top a couple of these. > > So anyone out there still wonder why you should always use RES to reserve > RAM? If I would this would not convince me: always CBLOCK would have prevented that error too. Hardcoding is the evil here, not CBLOCK. -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

> Anyway, variable definitions should go to a single place not just here and > there in the code which makes everything messy. If there were only one > cblock then that kind of mistakes could have been eliminated. The linker > script is however generally a good idea and even unavoidable if the source > is separated into files - but even then a 'res' here and there is not a good > practise. Why not? I would promote putting a RES near the code that needs it, not in some central place. -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Wouter van Ooijen wrote: > Olin Lathrop wrote: >> alan smith wrote: >>> The >>> original author used the cblock directive, but hardcoded some >>> variables at the bottom end of the RAM, and as I added some >>> additional variables it wrote over the top a couple of these. >> So anyone out there still wonder why you should always use RES to reserve >> RAM? > > If I would this would not convince me: always CBLOCK would have > prevented that error too. Hardcoding is the evil here, not CBLOCK. > I'm not sure I understand here. Two CBLOCK's can overlap, not ? Jan-Erik.

Jan-Erik Soderholm wrote: >> If I would this would not convince me: always CBLOCK would have >> prevented that error too. Hardcoding is the evil here, not CBLOCK. > > I'm not sure I understand here. > Two CBLOCK's can overlap, not ? Yes they can, since CBLOCK is for defining enumerated constants and has nothing to do with RAM addresses. CBLOCK is almost hard coding. You can still hard code the addresses of variabled defined with RES, but at least that way the linker catches it if you overlapped other variables or went outside the valid address range. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

> Why not? I would promote putting a RES near the code that needs it, not > in some central place. Because in my opinion it leads to laziness, it's like the C++ style "here we need a variable so lets just create it". And then hard to organise in which section it should be in, what will be the best to avoid to much bankings or to use overlays to be able to use less ram. Maybe I'm wrong on this but using section definitions (udata, udata_ovr, udata_acs whatever) + res all over my code feel like messy to me. Tamas On Tue, Jun 17, 2008 at 4:24 PM, Wouter van Ooijen <EraseMEwoutervoti.nl> wrote: {Quote hidden}> > Anyway, variable definitions should go to a single place not just here > and > > there in the code which makes everything messy. If there were only one > > cblock then that kind of mistakes could have been eliminated. The linker > > script is however generally a good idea and even unavoidable if the > source > > is separated into files - but even then a 'res' here and there is not a > good > > practise. > > Why not? I would promote putting a RES near the code that needs it, not > in some central place. > > -- > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: http://www.voti.nl > consultancy, development, PICmicro products > docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > -

Tamas Rudnai wrote: > Because in my opinion it leads to laziness, it's like the C++ style > "here we need a variable so lets just create it". And then hard to > organise in which section it should be in, what will be the best to > avoid to much bankings or to use overlays to be able to use less ram. I specify the bank most variables go in at assembly time, and generally put individual local variables of a module (as apposed to buffers or arrays) in the same bank. That allows for automatic assembly time bank settings, and minimizes bank switching between modules. I also usually put global variables in one known bank. On PIC 18 I usually use the access bank for global variables. The constants GBANKADR and LBANKADR are addresses within the banks chosen for global and local registers. These constants are used with my DBANKIF macro to set the banking state for access to those variables. DBANKIF tracks the bank setting at assembly time, and only produces the minimum instructions to switch from the current bank to the new. > Maybe I'm wrong on this but using section definitions (udata, > udata_ovr, udata_acs whatever) + res all over my code feel like messy > to me. It's definitely better than the alternative of not having self contained modules with their own namespace. Besides, variable definitions wouldn't be "all over the code". Generaly you do this in the same place at the top of every module. My module templates make this easy. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

> I'm not sure I understand here. > Two CBLOCK's can overlap, not ? Not if used properly: only one CBLOCK with a start value, most convenient place is in the processor header file. in the main code file (and included code sub-files) only CBLOCKs without start value. No overlaps this way, but still no check on the upper bound. -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

> -----Original Message----- > From: RemoveMEpiclist-bouncesEraseMEEraseMEmit.edu [RemoveMEpiclist-bouncesspam_OUTKILLspammit.edu] On Behalf {Quote hidden}> Of Jan-Erik Soderholm > Sent: 17 June 2008 16:39 > To: Microcontroller discussion list - Public. > Subject: Re: [PIC] 16F887 and corrupted RAM/EEPROM > > Wouter van Ooijen wrote: > > Olin Lathrop wrote: > >> alan smith wrote: > >>> The > >>> original author used the cblock directive, but hardcoded some > >>> variables at the bottom end of the RAM, and as I added some > >>> additional variables it wrote over the top a couple of these. > >> So anyone out there still wonder why you should always use RES to > reserve > >> RAM? > > > > If I would this would not convince me: always CBLOCK would have > > prevented that error too. Hardcoding is the evil here, not CBLOCK. > > > > I'm not sure I understand here. > Two CBLOCK's can overlap, not ? If you have a project with a single asm file linked with absolute mode (which probably accounts for the majority of small projects rightly or wrongly), then why would you have 2 CBLOCKs for your variables? Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. =======================================================================

>> Why not? I would promote putting a RES near the code that needs it, not >> in some central place. > > Because in my opinion it leads to laziness, it's like the C++ style "here we > need a variable so lets just create it". And then hard to organise in which > section it should be in, what will be the best to avoid to much bankings or > to use overlays to be able to use less ram. That might be a good idea when you are very very pressed for speed or (code) size and have enough time to do the hand-optimizing, but IMO in most cases the (programmer's time) benefits of modularity (I need a buffered UART output? let's just include the appropriate file!) are more important. -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

> If you have a project with a single asm file linked with absolute mode > (which probably accounts for the majority of small projects rightly or > wrongly), then why would you have 2 CBLOCKs for your variables? I can see only two 'legal' reasons, one is that because there are more than one ram area that are located in non-continuous places, and two because you would like to have overlayed data usage. Tamas On Tue, Jun 17, 2008 at 6:36 PM, Michael Rigby-Jones < RemoveMEMichael.Rigby-JonesTakeThisOuTspambookham.com> wrote: > > > > {Original Message removed}

> That might be a good idea when you are very very pressed for speed or > (code) size and have enough time to do the hand-optimizing, but IMO in > most cases the (programmer's time) benefits of modularity (I need a > buffered UART output? let's just include the appropriate file!) are more > important. That's true, however I think the kind of things like this the benefit of the usage of the linker script is highly valuable. Tamas On Tue, Jun 17, 2008 at 6:38 PM, Wouter van Ooijen <EraseMEwouterspamspamBeGonevoti.nl> wrote: {Quote hidden}> >> Why not? I would promote putting a RES near the code that needs it, not > >> in some central place. > > > > Because in my opinion it leads to laziness, it's like the C++ style "here > we > > need a variable so lets just create it". And then hard to organise in > which > > section it should be in, what will be the best to avoid to much bankings > or > > to use overlays to be able to use less ram. > > That might be a good idea when you are very very pressed for speed or > (code) size and have enough time to do the hand-optimizing, but IMO in > most cases the (programmer's time) benefits of modularity (I need a > buffered UART output? let's just include the appropriate file!) are more > important. > > -- > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: http://www.voti.nl > consultancy, development, PICmicro products > docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > -

Wouter van Ooijen wrote: > Not if used properly: only one CBLOCK with a start value, most > convenient place is in the processor header file. in the main code > file (and included code sub-files) only CBLOCKs without start value. > > No overlaps this way, but still no check on the upper bound. But then only if you use CBLOCK exclusively for creating variables. One set of enumerated constants, which is what CBLOCK is really for, and this scheme breaks. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

Olin said: > Yes they can, since CBLOCK is for defining enumerated constants and has > nothing to do with RAM addresses. Actually, although CBLOCK is certainly very useful for defining enumerated constants, I believe it was likely originally introduced as a convenient way to assign addresses to variables. Remember, that in most early (absolute) assemblers, there is no 'typing' of expressions, and thus it is not possible to distinguish a memory address from any other constant. This was certainly true in the early 8080/Z80 assemblers I used. -- Bob Ammerman RAm Systems

Quoting Bob Ammerman <RemoveMErammermanKILLspamverizon.net>: > Olin said: >> Yes they can, since CBLOCK is for defining enumerated constants and has >> nothing to do with RAM addresses. > > > Actually, although CBLOCK is certainly very useful for defining enumerated > constants, I believe it was likely originally introduced as a convenient way > to assign addresses to variables. > > Remember, that in most early (absolute) assemblers, there is no 'typing' of > expressions, and thus it is not possible to distinguish a memory address > from any other constant. This was certainly true in the early 8080/Z80 > assemblers I used. > > -- Bob Ammerman > RAm Systems The help file makes it clear what CBLOCK is intended for, like it or not. "cblock is useful for defining constants in program and data memory for absolute code generation". Absolute addresses of variables in data memory (and constants in program memory) *are* constants. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" s...STOPspamspam_OUTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com

Hi, Alan. I have noticed problems where the BOR is not working properly or is not used. Take a look there first. --Bob On Mon, Jun 16, 2008 at 10:07 PM, alan smith <spamBeGonemicro_eng2STOPspamEraseMEyahoo.com> wrote: {Quote hidden}> Client has a 16F887 in a product,and they do limited runs of 20 or so at a > time. Maybe one out of the batch shows problems that allude to that the ram > locations are being corrupted, and perhaps even EEPROM locations. The value > in the ram is loading a timer and so when its bad....the timer is way off. > It loads from EEPROM, and so the code allows the user to check the value and > its wrong. > > So what I am asking is.....has anyone seen issues where RAM locations get > corrupted? The client can run it 9 or 10 times, works fine (power cycle) > but then it fails...and the other boars being built run just fine. Bad > chips? I find that hard to believe these days. > > > > > -

Bob Ammerman wrote: > Actually, although CBLOCK is certainly very useful for defining > enumerated constants, I believe it was likely originally introduced > as a convenient way to assign addresses to variables. I'm sure that was the original intent, which I think is even still mentioned in the manual. However that was before relocatable mode and the linker existed. I'm trying to keep things simple in today's world where there has long been relocatable mode and the RES directive. That's why I say CBLOCK is for enumerated constants and RES is for variables. This should make it more clear for those that might get confused, and also doesn't even consider absolute mode as a option. Today the only excuse for absolute mode is having to do maintenence on archaic code, and even then converting it to absolute mode would be a good idea before making any changes. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

Apptech wrote: >> Today the only excuse for absolute mode is >> having to do maintenence on archaic code, and even then >> converting it to >> absolute mode would be a good idea before making any >> changes. > > Minor but beginner-confusing typo I think. > >> ... and even then converting it to absolute mode > > should be > >> ... and even then converting it to relocatable mode Doh! Thanks for the correction. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.