89C51ED2
in [Design]
|
From: Eeyore on 3 Sep 2008 22:36 Joerg wrote: > TT_Man wrote: > > > > Joerg, I get regular updates on all atmel processor revision changes/data > > sheet spec changes, . In this respect, Atmel are 100% on the ball. > > AFAIK there have been none for this particular part...... > > That's good. I'd call them anyhow though. I once had an issue with them > regarding an 89C51 that was advertized at a higher clock than it could > do. IIRC it was touted as 16MHz but I could only get it to run at 12MHz. > They did apologize and other than that it ran in that same design > forever. In fact, it's still in production, over a decade now. That's > the beauty of 8051 designs, those things are like the VW Beetle. They're little sweeties and some of the NXP (ex-Philips) varaints are awesome. One I found with an on-board LCD controller. 68 pin IIRC. And because the basic kernel is so easily expandable, it's a doddle to use these extras. Graham
From: JosephKK on 4 Sep 2008 01:01 On Wed, 3 Sep 2008 20:39:38 +0100, "TT_Man" <Someone(a)ntlworld.com> wrote: >>> >> 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... > Interesting, i was thinking of process change induced timing changes. Particularly changes in setup and hold parameters. You might profitably check for that. Or it could be a wild goose chase.
From: JosephKK on 4 Sep 2008 01:56 On Wed, 03 Sep 2008 14:56:21 -0700, Joerg <notthisjoergsch(a)removethispacbell.net> wrote: >mpm wrote: >> On Sep 3, 1:13?pm, "TT_Man" <Some...(a)ntlworld.com> 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... >> >> Is this an Atmel part? >> If so, I would check the datasheets for updates. >> I know on their 8252/3 series, they made a change to the crystal cap >> requirements. >> Went from 30pf to around 5pf. Would occasionally cause improper >> startup/reset, and very slow operation if it did reset. If they >> changed the oscillator on ED2, that could very well be the problem. >> (?) >> > >Hopefully not without changing the rev level and informing their >customers? Yikes, I sure hope not. Actually these days i would expect that. Perhaps million unit per month customers would be informed, even more likely, one of them requested it. cf. process change breaks timing margins.
From: TT_Man on 4 Sep 2008 05:05 "Eeyore" <rabbitsfriendsandrelations(a)hotmail.com> wrote in message news:48BF4043.AE375BE5(a)hotmail.com... > > > 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... > > Have you contacted the manufacturer ? > > Graham > > Yes, that was my first port of call, with full details, source code etc.and an indication of the approximate area of failure, within 10 lines of code......
From: Eeyore on 4 Sep 2008 06:16
TT_Man wrote: > "Eeyore" 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... > > > > Have you contacted the manufacturer ? > > Yes, that was my first port of call, with full details, source code etc.and > an indication of the approximate area of failure, within 10 lines of > code...... How does the defect manifest itself ? 8051s have been 'rock solid' IME. As someone else memtioned, do you have a critical timing issue anywhere ? Like an I/F chip maybe ? Are PSEN, ALE, /WR and /RD all clean ? You're probably not using PSEN but never hurts to check. No-one's messed about with the clock oscillator parts have they ? What do the 10 lines of code do ? Graham |