I have a problem with downloading my user program in some ADuC812
microcontrollers with windows serial downloader. When I try to reset the
ADuC812 with WSD, it returns with: reseting failed.
We have put together some debug guidelines from previous experience of the
common issues that cause resetting failures. Please check these issues on your
Resetting failures can be caused by a number of things. Some of the more common
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
UART when reset with the PSEN pin pulled low. You can verify this by opening up
Hyperterminal on windows (in VT-100 mode, at 9600baud, 8bits, no-parity, 1-stop
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 hyperterminal (via the
9600COM1.ht file if possible) and see if it is able to connect. If it is,
the port is free. Be sure to close hyperterminal (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 baud 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 options.
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
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 www.analog.com/microconverter ).
Can you answer the following questions for me:
1) Can you confirm that /PSEN is less than 0.8V before RESET is taken low?
2) What reset circuit are you using?
3) What rise time do you normally have on VDD in your system?
4) If you use a fast rise time on VDD and a clean reset signal are you able to
enter serial download mode?
The current errata for ADuc812 can be found at: