Search FAQs on the left to see if your question has been answered. Click on the dropdown to view all of the documents associated with the product. If you can't find your question, click on Ask a Question.

ADUC812: Failure to Reset/Download

At programming AduC812 of production after 2001
the chip is written 1-2 times by the program download.exe version 2.07 well.
At the subsequent attempts to write AduC812 by the program download.exe version
2.07 the reset of the chip and record is not fulfilled.
I ask you to explain that in this case it is necessary to do.


Error message: "Resetting the target device: Failed"..…..therefore subsequent
failure to download.

This can be caused by a number of things. Some of the more common ones:
1. The chip is not connected to the correct COM port. Verify COM1 connection or
correct software switch to other port.

2. The chip is not powered up or not in download/debug mode.
To verify download/debug mode, check that the chip spits out the reset string
from its
UART when reset with the PSEN pin pulled low. You can verify this by opening up
Hyper terminal on windows (in VT-100 mode, at 9600baud, 8bits, no-parity,
1-stop bit) and
connecting to COM1 (or whatever). See below for more information on placing the
ADUC812 in serial download mode.

3. The selected port (COM1 default) is being used by other software.
Even if the downloader says something like "Initializing Com1 at 9600
baud:.....OK!" it does not necessarily mean that it really was successful at
opening the port.
Many common applications (such as Palm HotSync manager) can run in the
background and
prevent other programs from using the serial port. Disable these programs (in
the lower right
of the windows taskbar) to free up the serial port. To ensure that the serial
port is free, launch
hyper terminal (via the file if possible) and see if it is able to
connect. If it is,
the port is free. Be sure to close hyper terminal (or hit disconnect) before
running the
downloader again.

4. The downloader and the chip are talking at two different baud rates.
If the ADuC812 is running with an 11.0592MHz crystal (like on the eval board)
then it
communicates at 9600baud with the downloader, which is the downloader's default
rate. To download to chips at different crystal frequencies, a switch must be
used on the
command line for the DOS downloader to indicate the target's clock speed. Type
"/help" in
place of the file name when launching the downloader to get a list of download

5. The security bit is set (ADuC812).
If the last program to successfully go onto the chip contains any commands to
program the
640 byte Flash/EE data space, then it's possible that a simple programming
error caused a
write to page 160 resulting in the security bits getting set and locking the
chip up for good.
There's no way to recover other than replacing the chip. Code must be written
carefully to
ensure that page 160 of data Flash/EE space never gets programmed. See errata
#7 (errata
revs E & D) for details.

In conjunction with the above,  there are a number of things which could
prevent the ADuC812 to enter serial download mode.

First consider that the ADuC812 may not be receiving a valid RESET condition
which forces it into serial download mode.
The PSEN pin is normally configured as an output. When the RESET pin is
asserted, the PSEN pin is configured as a digital input and the only current in
or out of the pin should be leakage current (which we measure to be 10nA).
Therefore, when RESET is brought high, the voltage at PSEN should be very close
to ground.  When RESET is released, the voltage at PSEN is sampled on the
falling edge of RESET and the part will go into serial download mode if the
voltage at PSEN is interpreted as a logic low.

Could I ask you to measure the voltage at PSEN while the RESET pin is held high
with the 1k pull-down resistor. If you do not see a voltage very close to zero,
it is possible that something else is driving PSEN high. 

Does your program write to the on-chip EEPROM (User FLASH)?
If it does, then consider the possibility that you are writing to memory
locations which are higher than page 159. If you write to pages 160 or higher
there is a strong possibility that you will set the security bits on the
ADuC812.  We have removed all mention of the security bits from the datasheet
and we strongly recommend that users do not try to use them. This feature is
not fully tested and is not guaranteed. If you set the security bits, you will
not be able to enter the serial download or debug modes and you have
effectively locked yourself out of the code space on the ADuC812.

If you think you may have accidentally set the security bits, you can recover
the part by placing the part in parallel programming mode and executing an
ERASE ALL command (as described in the datasheet). You should then be able to
enter serial download and debug modes again. If the above procedure allowed you
to recover operation of the ADuC812, you will then have to analyse your code,
work out how you wrote to the higher Flash pages and alter your code to fix the

Reset generator
The recommended reset circuit for use with the ADuC812 is an active high reset
generator preferably with in built delay of approx 100ms such as the ADM810.
Note that an active low reset generator through a logic inverter is not
acceptable. Logic inverters to not guarantee their output state during power up
and power down and can cause glitches on the reset. Ensure that you are using
an  active high reset circuit similar to the ADM810. Take a look a the RESET
pin on the ADuC812 on a 'scope during power up and look at VDD on the other
channel of the scope. Capture on a digital 'scope what happens during power up
an power down. Look for any glitches on reset (you may have to cycle power many
times to capture a glitch). Also look for any instance where the ADuC812 is
released from reset with lower than spec powers supply. The reset signal should
at all times conform to the timing diagram given in the latest datasheet REV.A
(available from ).