Problem with Atmel micro in a Kaon TV decoder

191 views
Skip to first unread message

Jeroni Paul

unread,
Apr 23, 2011, 1:00:51 PM4/23/11
to
I have a Kaon satellite/terrestrial decoder that while starting up it
will reboot several times until it works. After a lot of checking and
testing it seems the front panel micro AT89S52 sometimes won't wait
long enough for all the hardware to initialize. Precise measurements
on the communications between this micro and the main video decoder
reveal that the hardware initializes always at the same speed and it
is the AT89S52 micro that sometimes waits longer and thus starts
successfully but sometimes aborts too early. I don't know what else to
check: supply 5V to the micro perfectly clean, even added capacitors
to check, clock clean (has its own 12MHz crystal). Don't know what
else to check, I can only conclude the micro is faulty. Unfortunately
I don't have the code that runs inside so I don't know if that delay
is implemented by a loop or a hardware timer.
Any ideas?

Rich Webb

unread,
Apr 23, 2011, 1:31:27 PM4/23/11
to

Hold it in a reset state longer on startup. These guys are unusual in
that their RST pin is active high, so keep that in mind.

The naive way to implement reset in this family is just a cap to the
positive supply rail, a resistor to ground, and the RST pin in between.
If this is what they used, it sounds like you're just on the edge of
reliability and may be able to make it happy by boosting the RC time
constant a tad by using a larger C or R, depending on which is easier to
get to.

There are also "supervisory" chips that are more reliable and can also
take care to reset on brown-outs. Some of these hold reset active for a
fixed interval but, IIRC, some set the time with an external R or C.

--
Rich Webb Norfolk, VA

Jamie

unread,
Apr 23, 2011, 1:58:52 PM4/23/11
to
Jeroni Paul wrote:

Look on the board that has the micro for some electro caps. I work with
those types of CPU's and what I have done for a synchronized start up
is to employ a delay circuit for the CPU, a sort of power management
process. Check the caps to make all are up to snuff.. A low valued
cap is going the allow the CPU to start sooner in the power management
section. If this is a new problem, either the main unit is taking too
long, indicating a hardware problem or you do have something strange
going on. You may want to check for bad caps and solder joints, a very
common problem. Especially with today's Lead Free solders.


Jamie

Jeroni Paul

unread,
Apr 23, 2011, 3:53:45 PM4/23/11
to
On 23 abr, 19:31, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
> Hold it in a reset state longer on startup. These guys are unusual in
> that their RST pin is active high, so keep that in mind.
>
> The naive way to implement reset in this family is just a cap to the
> positive supply rail, a resistor to ground, and the RST pin in between.
> If this is what they used, it sounds like you're just on the edge of
> reliability and may be able to make it happy by boosting the RC time
> constant a tad by using a larger C or R, depending on which is easier to
> get to.
>
> There are also "supervisory" chips that are more reliable and can also
> take care to reset on brown-outs. Some of these hold reset active for a
> fixed interval but, IIRC, some set the time with an external R or C.
>
> --
> Rich Webb     Norfolk, VA

Thank you for the replies.
I tried to keep the reset input active manually for several seconds
but still behaves the same. What happens while RST is high is the
micro sets some outputs high and turns on all the hardware. When I
remove RST all comes back to st-by. From then on the behaviour is the
same. For reset it uses a KIA7436P:
http://www.alldatasheet.com/datasheet-pdf/pdf/69424/KEC/KIA7436P.html

Jeroni Paul

unread,
Apr 23, 2011, 5:19:16 PM4/23/11
to
On 23 abr, 19:58, Jamie

<jamie_ka1lpa_not_valid_after_ka1l...@charter.net> wrote:
> Look on the board that has the micro for some electro caps. I work with
> those types of CPU's and what I have done for a synchronized start up
> is to employ a delay circuit for the CPU, a sort of power management
> process. Check the caps to make all are up to snuff.. A low valued
> cap is going the allow the CPU to start sooner in the power management
> section. If this is a new problem, either the main unit is taking too
> long, indicating a hardware problem or you do have something strange
> going on. You may want to check for bad caps and solder joints, a very
> common problem. Especially with today's Lead Free solders.
>
> Jamie

Thank you.
There are two electrolytics, one in parallell with 5V supply and
another after a 47 ohm resistor to supply the IR sensor. There are
some resistors to power the leds and buttons and I see no other
components that could be used for a delay.

This micro is connected to a VFD driver chip to show the time, channel
number, etc to a VFD display. While starting it shows some moving
dashes on the 7-segment part, then the text "on" and then reboots. If
it doesn't reboot then shows "Init" and the last channel number. There
is no visible difference in the moving dashes between a good and a
failed initialization but when it starts fine, the "on" text keeps
slightly longer on the display, around 1 additional second, being all
the signals it receives from the main unit the same. This additional
one second is what makes the difference.

Rich Webb

unread,
Apr 23, 2011, 6:42:29 PM4/23/11
to

Humph. So much for the easy fix. ;-)

Any chance that the manufacturer has a firmware fix for this? The
AT89S52 is in-system programmable so it might be possible to load new
firmware in the field. If there is such a thing available they may not
want to release it to an end user (too much chance of bricking the unit)
but you sound like you know what you're doing and *if* there is one
available you might be able to convince them you're okay.

Otherwise, it may be time to get creative. One possibility might be to
run the CPU at a slightly slower speed by increasing the load capacitors
at the crystal. Or, replace the 12 MHz crystal with an 11.0592 MHz
(should be available). Might work, depending on what other timing
sensitive parts that it talks to.

Jamie

unread,
Apr 23, 2011, 8:56:10 PM4/23/11
to
Jeroni Paul wrote:

It sounds like a Lead free solder joint problem.. If you can yourself
a hot air gun ( not a hair dyer, not hot enough), you can maybe fix this
problem by concentrating hot air on the suspected. Its very hard to see
defected Lead free joints. Also from what you are saying it almost
sounds like the problem is down on the main board.

Jamie

Jeroni Paul

unread,
Apr 23, 2011, 8:58:22 PM4/23/11
to
On 24 abr, 00:42, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
> Humph. So much for the easy fix.  ;-)
>
> Any chance that the manufacturer has a firmware fix for this? The
> AT89S52 is in-system programmable so it might be possible to load new
> firmware in the field. If there is such a thing available they may not
> want to release it to an end user (too much chance of bricking the unit)
> but you sound like you know what you're doing and *if* there is one
> available you might be able to convince them you're okay.
>
> Otherwise, it may be time to get creative. One possibility might be to
> run the CPU at a slightly slower speed by increasing the load capacitors
> at the crystal. Or, replace the 12 MHz crystal with an 11.0592 MHz
> (should be available). Might work, depending on what other timing
> sensitive parts that it talks to.
>
> --
> Rich Webb     Norfolk, VA

Unfortunately Kaon appears to have removed any support for this model
from their web and months ago I sent them an email asking for a
firmware upgrade and got no reply.
When this box was given to me it had an older firmware version and it
was so buggy it rendered the box useless, this is why it was given to
me. In that time some channels started transmitting some sort of DVB
subtitles that caused it to hang. I upgraded the firmware to the
latest I could find out there and that fixed many bugs including the
hang with subtitles. I then noticed the reboot problem, but I don't
know if it existed with the previous firmware. Since it was so
intermittent and difficult to trace I decided to keep using the
decoder and see if it would get worse or fail completely but after two
years it has not changed its behavior.
Now that you mention the firmware I will look at it again. Maybe I
should try to install some intermediate version in the hope it will
upgrade the code in the Atmel. Maybe I jumped too far from a too old
version.

If it were easier to remove the crystal I would have already tried a
lower frequency one but it is sandwiched under the VFD panel. I tried
to put a lower frequency crystal in parallel to the current one but it
makes no difference, maybe the current one has lower impedance? Anyway
I think lowering the frequency will break programmed recordings which
is one of the interesting features of this decoder, since the Atmel
keeps a clock and at least the time it has to power on to start a
recording (I believe programmed recordings work this way since it is
the only alive processor while in st-by). By the way, when it awakes
to perform a programmed recording it has the same reboot behavior.

Rich Webb

unread,
Apr 23, 2011, 10:01:38 PM4/23/11
to
On Sat, 23 Apr 2011 17:58:22 -0700 (PDT), Jeroni Paul
<JERON...@terra.es> wrote:

>If it were easier to remove the crystal I would have already tried a
>lower frequency one but it is sandwiched under the VFD panel. I tried
>to put a lower frequency crystal in parallel to the current one but it
>makes no difference, maybe the current one has lower impedance? Anyway
>I think lowering the frequency will break programmed recordings which
>is one of the interesting features of this decoder, since the Atmel
>keeps a clock and at least the time it has to power on to start a
>recording (I believe programmed recordings work this way since it is
>the only alive processor while in st-by). By the way, when it awakes
>to perform a programmed recording it has the same reboot behavior.

Hmmm. May have to sleep on this one.

Does the processor's oscillator stay running while the device is in
standby? The 89S52 does have a sleep mode where it turns the oscillator
off but if it is responsible for waking up the rest of the device then
I'd guess that it must stay running.

If the oscillator stays running, given that the problem behavior also
occurs when it goes to wake up the rest of the system from a state where
it itself has already initialized, then it does sound like a firmware
problem. Might be something like: wait for N timer ticks and if X has
not happened then perform error recovery; but the actual time between N
ticks can range from (N-1) to (N+1) if the waiting started just before
or just after a tick event.

Jeroni Paul

unread,
Apr 24, 2011, 9:20:19 PM4/24/11
to
On 24 abr, 04:01, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
> Hmmm. May have to sleep on this one.
>
> Does the processor's oscillator stay running while the device is in
> standby? The 89S52 does have a sleep mode where it turns the oscillator
> off but if it is responsible for waking up the rest of the device then
> I'd guess that it must stay running.
>
> If the oscillator stays running, given that the problem behavior also
> occurs when it goes to wake up the rest of the system from a state where
> it itself has already initialized, then it does sound like a firmware
> problem. Might be something like: wait for N timer ticks and if X has
> not happened then perform error recovery; but the actual time between N
> ticks can range from (N-1) to (N+1) if the waiting started just before
> or just after a tick event.
>
> --
> Rich Webb     Norfolk, VA

The oscillator is running all the time. Don't know if it goes to some
idle mode but signals from the IR sensor and buttons change INT0 input
(pin 8 of TQFP package).

I tried to downgrade to an older firmware and the behavior is the
same. I think flashing another firmware only changes the firm for the
video decoder and not the code in the Atmel.

I thought maybe stopping the oscillator for a second or two while in
the wait loop will fix the problem. I tried to manually ground the
crystal output (I can see the dashes stop moving) and when it works it
doesn't reboot, but sometimes will go crazy probably due to poor or
intermittent contact I do with a wire to the crystal solder joint.

Rich Webb

unread,
Apr 24, 2011, 10:32:10 PM4/24/11
to

Something like that might be an option. If you could identify a pin that
changes state when it begins the operate sequence that's giving you
trouble, use that event to slow down the clock just long enough to get
past the difficult spot.

Something like (block diagram; use fixed-pitch)

.-------.
| |
| |
|12 MHz o-----o-------------------.
| | | |
'-------' ? |
| |
.-----o----. .------o------.
| | | |
.----o one-shot o-------o divide by 2 o------.
| | | | | |
| '----------' '-------------' |
| |
.-o--------------------------------------------o---------.
| the pin X1 |
| |
| 89S52 |
| |
'--------------------------------------------------------'
(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)

Where the event on "the pin" fires the one-shot (could be a counter
that's run from the 12 MHz clock or maybe the old standby, a 555). That
enables the divide by 2 so you briefly run at 6 MHz, slowing everything
down.

Of course, an external clock and a crystal oscillator won't play well
together. But this would probably want a small daughter board, anyway,
and you could disconnect the crystal altogether and run with a canned 12
MHz oscillator.

It wants a clocked flip-flop somewhere there so that it changes speed
cleanly.

Jeroni Paul

unread,
Apr 26, 2011, 3:57:18 PM4/26/11
to
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.

Rich Webb

unread,
Apr 26, 2011, 6:53:03 PM4/26/11
to

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.

Jeroni Paul

unread,
Apr 28, 2011, 8:51:53 PM4/28/11
to
On 27 abr, 00:53, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
> 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

After trying many solutions this is the simplest working one:

VCC
+
|
.-.
| |
100K| |
'-'
|
+--> /OE
|
___ |/
/RST >--|___|-+----| BC548
560K | |>
|+ |
4.7uF === |
/-\ |
|______|
|
===
GND


(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)

The 100K pull-up resistor keeps all outputs in tri-state during power
up ramp as per LCX244 datasheet and it actually works. When /RST goes
high it will start to charge the capacitor slowly and some hundred
milliseconds later will polarize the transistor that will ground /OE
and enable communication with a perfect transition. I have tested this
in a proto board with wires soldered to the unit and works great, have
been turning on and off the unit repeatedly now and then and no more
reboots!

Initially I targeted to remove the slow ramp only and it did not fix
the issue. Apparently the ramp does not cause the reboots or is not
the only reason for them. So I increased the delay to also remove two
or three bursts received from the main unit that look like ACK of some
sort as they are all very short and appear to carry no useful
information at all (I can't say they cause the reboots because they
are present and are identical when it starts fine). I adjusted the
delay so that communication will be enabled around 100ms before the
first useful burst and that appears to do the trick.

Thank you so much for all your help!

By the way this is a Kaon KVR-1000TS+

Rich Webb

unread,
Apr 29, 2011, 8:39:09 AM4/29/11
to

Good news and excellent troubleshooting to zero in on the problem!

Jeroni Paul

unread,
May 1, 2011, 8:45:06 PM5/1/11
to
On 29 abr, 14:39, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
> >By the way this is a Kaon KVR-1000TS+
>
> Good news and excellent troubleshooting to zero in on the problem!
>
> --
> Rich Webb     Norfolk, VA

To add to the subject I have found an alternative fix for the problem.
I found out how easy is to read and write the firmware in this Atmel
micro with ISP in this web: http://ikalogic.com/isp.php
Required signals are available in a 6 pin connector on the front panel
board, seen from the front it looks like:
5 3 1
6 4 2

1 - MISO
2 - 5V
3 - SCK
4 - MOSI
5 - RST
6 - GND

So I went on and wired these pins to a parallel port as required by
the "ISP Programmer" software and could read the flash memory
successfully. Then looked for a disassembler (surprise, this Atmel
uses the 8052 instruction set) so I used one called DIS8051. I was for
many hours trying to follow the code path, looking at the interrupt
handlers and trying to understand how it was supposed to work. Had to
create a tags file for the disassembler to tell what to interpret as
data and instruction and finally got a proper disassembly without
undefined references.

It turns out the communication between the Atmel and main decoder is
performed through a serial interface using its builtin UART, and the
so sensitive input was the UART RXD. Interrupt handler that handles
UART ignores TI (transmission) interrupts and on RI (reception) only
takes read data and adds it in a circular buffer. Other parts of the
code read these RAM addresses but I have not gone further this way. I
was interested in finding the proper place during initialization where
to inhibit reception or delete whatever was read from the serial port.

At turn on the Atmel generates a RST signal for all the hardware and I
happened to identify where this signal is generated. The function
setting the port output used for RST has a software delay (no timers)
and while it is executing is when the supply turns on and apparently
reads some garbage causing the reboot problem. The function is
surrounded by CLR ES and SETB ES, this disables interrupts from serial
port but I think if some noise or garbage is received it will remain
in the buffer and will be read as soon as the interrupt is reenabled.
So I changed these two instructions to CLR REN and SETB REN that
instead will inhibit reception in the UART.

Once edited I used the 8051 assembler ASEM to generate the file to be
loaded. This assembler comes with lots of MCU definitions and it also
has the 89S52. In the source the directive $INCLUDE (89S52.MCU) must
be added and command line parameter /INC:MCU must be specified
otherwise it will not recognize Timer2 registers (T2CON etc.).
A file compare between the original Intel-hex file and the assembled
one reveals only two bytes changed plus line checksum, thus
dissassembly and reassembly was perfect. Then I loaded the modified
code to the Atmel and the solution works!

So for now there are two solutions to the reboot problem, exposed in
previous messages was a circuit hack and here a firmware hack. These
are the relevant parts of the code:
The function that generates RST signal:
L0FD9: SETB P2.1 ;0FD9 D2 A1
MOV R7,#010H ;0FDB 7F 10
MOV R6,#027H ;0FDD 7E 27
LCALL L0E96 ;0FDF 12 0E 96
CLR P2.1 ;0FE2 C2 A1
MOV R7,#010H ;0FE4 7F 10
MOV R6,#027H ;0FE6 7E 27
LCALL L0E96 ;0FE8 12 0E 96
SETB P2.1 ;0FEB D2 A1
RET ;0FED 22
Function L0E96 performs a delay based on R6 and R7. The caller is
function at address 0850 and the relevant code is:
CLR ES ;0873 C2 AC
LCALL L0FD9 ;0875 12 0F D9
SETB ES ;0878 D2 AC

I changed CLR ES to CLR REN and SETB ES to SETB REN. Once compiled a
compare reveals this line with differences:
:10087000120F01C2AC120FD9D2AC12106A7897765F
:10087000120F01C29C120FD9D29C12106A7897767F

I hope it may be useful.

Rich Webb

unread,
May 2, 2011, 8:10:10 AM5/2/11
to
On Sun, 1 May 2011 17:45:06 -0700 (PDT), Jeroni Paul
<JERON...@terra.es> wrote:

>On 29 abr, 14:39, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
>> >By the way this is a Kaon KVR-1000TS+
>>
>> Good news and excellent troubleshooting to zero in on the problem!
>>
>> --
>> Rich Webb     Norfolk, VA
>
>To add to the subject I have found an alternative fix for the problem.

[snippety snip]

Holy crap! That's some detailed analysis.

You know, you've got the material for a pretty good magazine article
there. Put together an abstract and point an editor or two to the
thread. Who knows?

hans...@gmail.com

unread,
Sep 4, 2012, 4:19:39 AM9/4/12
to
Hi guys,

I don't know if anybody is still reading this, but let's give it a try...

I have the same Kaon Receiver with the same problem. Annoying, but after a minute or so it finally boots so that was fine enough for me. For some years (...).

However, after I got back from holiday this year I have a new problem: Generally I never fully switch off the unit (with the mains switch), but for this holiday I did. After I got back I wsitched the unit back on, and now it doesn't pass the boot cycle any more. The display first shows the moving segments (a couple of seconds) and then shows "on", and then it's stuck... It output's no signal to the TV, not even the menu or anything similar

I suspected some memory battery problem, but it doesn't seem to have one.

Anybody any idea?

Thanks in advance for any help, because obviously Kaon is not of much help :(
Reply all
Reply to author
Forward
0 new messages