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?
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
formatting link
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
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?
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 year= s (...).
However, after I got back from holiday this year I have a new problem: Gene= rally I never fully switch off the unit (with the mains switch), but for th= is 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 se= gments (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 = :(
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.