On 29 abr, 14:39, Rich Webb 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.