Re: 89C51ED2

Not a prayer in hell 100% assembler. :)

Are you using interrupts?

">>

Everything is interrupt driven. Processor spends 99% in sleep mode.Int routines set flags and the background processes flags, then goes back to sleep. Dual 3 of 5 uarts are processed with 125uS RTC.

This raises a BIG red flag for me - how long does the uP take to come out of sleep mode? How's the interrupt latency? Did it used to block other interrupts, or could they be stepping on each other?

But I've never trusted "sleep mode" - probably because it takes me about

3 hours after getting up, before I'm fully awake. ;-)

Do you have a little "morning eye-opener" circuit? ;-D

Good Luck! Rich

This is done all the time. First time I used the PCON features on a

88C51 was in the early 90's. You have to make sure it does a controlled wake up (socks, shoes, brush teeth, etc.) and know the time it takes. When you build analog/RF stuff where there needs to be radio silence you've got no other choice.

Back in the army one guy's eye opener circuit consisted of a serious stash of booze in the locker. Beats me how he evaded detection by the drill sergeant. By lunchtime you couldn't light a cigarette near the guy or there would have been an explosion.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

I think you need to look very carefully at the interrupt code to make sure that it doesn't forget to save part of the context. This sounds like it is either timing related or an uninitialized flag.

8051s have a built in interrupt lock out and priority system. I doubt that he is getting into multiple levels of interrupts.

Latency is 1 instruction cycle.

No. The code runs perfectly in old date code devices and has been in production world wide for 15 odd years in one form or another.

As I pointed out elsewhere, the memory locations in a given chip tend to go to one value on power up. On a different chip they will go to a different value. If you forgot to initialize something, this will make some devices work and others fail.

The timing related problem will only show if you have external inputs other than the clock and reset pins. The true false boundary varies from chip to chip and run to run.

All inputs are flagged and re checked 25 ms later, If true , a flag change is set....

It could be a narrow window of timing that is causing the problem. Try changing the clock speed just a a little and see if the problem goes away.

Why should I? The problem lies in the manufacture of the chip, not my code. In any case, if it's missed by 1 nanosecond, it will catch it next time round, unless you can pull and release a trigger within 100 microseconds...

I'm thinking that there really may be a problem in your code when you have something like contact bounce.

Get real, contact bounce is handled in a 25mS background routine.........

...after the oscillator starts.

--
Keith