89C51ED2
in [Design]
|
From: TT_Man on 3 Sep 2008 13:13 Anyone using this part experiencing problems? we have used them for 4 years or so. Date codes up to 0705 work ok, 0814 misbehaves....same chip, same software, 0814 doesn't execute properly...
From: Jamie on 3 Sep 2008 13:49 TT_Man wrote: > Anyone using this part experiencing problems? we have used them for 4 years > or so. Date codes up to 0705 work ok, 0814 misbehaves....same chip, same > software, 0814 doesn't execute properly... > > Many times people carelessly take into account a condition of a uC that's there and makes it easier to code with even though the condition may not be documented. One day the maker of the chip decides to do something different and ensures that all prior documented functions in the chip are supported. One such case I can think of is assuming that memory would be zeroed out at start up. This could lead to some problems. Also, extra bits in a status register that meant nothing now be set HIGH instead of LOW which could lead to problems if code wasn't excluding these bits out of a test or, additional bit functions that never were supported and ignored and should have been set low are now supported and causing your code to not behave.. Those are just examples.. You may want to get a newer compiler if you're using a higher level than ASM. the compiler could be generating code that is not taking these conditions into account. http://webpages.charter.net/jamie_5"
From: TT_Man on 3 Sep 2008 15:39 >> > Many times people carelessly take into account a condition > of a uC that's there and makes it easier to code with even > though the condition may not be documented. > One day the maker of the chip decides to do something different > and ensures that all prior documented functions in the chip > are supported. > One such case I can think of is assuming that memory would > be zeroed out at start up. This could lead to some problems. > Also, extra bits in a status register that meant nothing now > be set HIGH instead of LOW which could lead to problems if code > wasn't excluding these bits out of a test or, additional bit > functions that never were supported and ignored and should have > been set low are now supported and causing your code to not behave.. > > > Those are just examples.. > > You may want to get a newer compiler if you're using a higher level > than ASM. the compiler could be generating code that is not taking these > conditions into account. I know all about those types of problems, not applicable. The product has evolved from a basic 51 controller back in 1989, all written in assembler, no funny undocumented codes/bits, very simple very basic software. Thousands out in the field blah blah. As I see it, I can find no die revisions that would be the obvious cause ( as on many atmel parts) In fact, I can't see any documented die revisions at all. It has probably been stable since they bought the rights to the device years ago. I'm hoping Atmel app. engineers will throw some light. Perhaps they moved the silicon production from A to B......inadvertantly introducing an obscure mask fault. There aren't many other possibilities...
From: Joerg on 3 Sep 2008 15:54 TT_Man wrote: > Anyone using this part experiencing problems? we have used them for 4 years > or so. Date codes up to 0705 work ok, 0814 misbehaves....same chip, same > software, 0814 doesn't execute properly... > Did you check the POR situation? Maybe issue a nice long POR and see if it'll run? The POR circuit on most 8051 is %^&#!! <tantrum censored> so I always rolled my own. As for BOR, I think many uC designers don't know what that means ... -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
From: Jim Thompson on 3 Sep 2008 16:11
On Wed, 03 Sep 2008 12:54:56 -0700, Joerg <notthisjoergsch(a)removethispacbell.net> wrote: >TT_Man wrote: >> Anyone using this part experiencing problems? we have used them for 4 years >> or so. Date codes up to 0705 work ok, 0814 misbehaves....same chip, same >> software, 0814 doesn't execute properly... >> > >Did you check the POR situation? Maybe issue a nice long POR and see if >it'll run? > >The POR circuit on most 8051 is %^&#!! <tantrum censored> so I always >rolled my own. As for BOR, I think many uC designers don't know what >that means ... I do ;-) I have some really nice designs, but you can't duplicate them in discrete form :-( ...Jim Thompson -- | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at http://www.analog-innovations.com | 1962 | It's what you learn, after you know it all, that counts. |