On Tue, 26 Apr 2011 12:57:18 -0700 (PDT), Jeroni Paul
wrote:

Before going further with messing the clock I rechecked my previous
measurements and tests and did some more tests to try to understand
how the Atmel behaves or should behave. I concluded it is supposed to
work this way: at turn on within the first second the Atmel receives
some bursts of data from the video decoder, then it waits indefinitely
while the main unit turns on (that when starts fine) and once up and
running the main unit starts sending bursts regularly. Upon reception
of the first regular burst the Atmel sets a 9 second time-out where if
nothing is received it reboots as it assumes the main unit is stuck.

The problem is it is starting that 9 second time-out right from the
beginning. At first I was thinking the bursts received within the
first second were triggering the start of time-out but I have found
sometimes after receiving these bursts it will still wait
indefinitely. I've compared good and failed start-ups on the digital
analyzer and the bursts received within the first second are
identical, so they can't be the cause. There is one thing I think may
be the culprit. At the very beginning when the main supply turns on
the digital analyzer shows some random oscillations that I already had
seen but I could not see a relation between them and the reboots since
sometimes it was a clean transition and rebooted and viceversa and I
belived the Atmel had to be ignoring that. Now I belive it is
intepreting that as regular bursts as if the main unit was already up
and running and starts the 9 second time-out.

These oscillations are not real but a result of a straight ramp from 0
to 3.3V lasting 10ms as seen on the scope. When the Atmel activates
the main supply the 3.3V and 5V outputs raise with that ramp,
propagates through buffer LCX244 and ends in the Atmel data input, to
me seems a poor design. The AT89S52 datasheet does not mention schmitt-
trigger inputs, so if they are normal inputs it is likely it sees
random oscillations.

I was testing to momentarily short data input to eliminate the ramp
and it seems to work but I may be killing the first bursts of data
too, so I would not claim victory until I implement a circuit to kill
that ramp and allow the bursts. I could insert a schmitt-trigger
buffer in the data input or I could place a circuit to keep the data
input shorted to ground for the first 100ms after the supply turns on.

Yes, slowly rising supplies can be a killer.

Holding /OE of the LCX244 might do the trick. The old standby RC setup
would probably work, although one of the many supervisory chips would be
more robust.

--
Rich Webb Norfolk, VA