89C51ED2

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...

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 %^&#!! 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

Meantime some pretty good POR/BOR chips have shown up. That was different in the 90's where you just couldn't trust many of them.

Body Odor Reset? ;-)

Cheers! Rich (my "real" guess is brown-out. ;-) )

rs

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. (?)

-mpm

Bacardi on the rocks :-)

Hopefully not without changing the rev level and informing their customers? Yikes, I sure hope not.

">> Is this an Atmel part?

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.

Thats not true. My bosses VW bug finally shit the bed not to long ago! :)

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.

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.

Yeah, but how old was it by then?

Well! 40 years is a respectable life for a car.

Ok, its a 1968 :)

Guess that last side collision he had didn't do the under structure to good! :)

If I could get an 8051 equivalent but with Motorola's timer system (see

Cheers! Rich

But crashing it doesn't help much. )-;

Cheers! Rich