Atmel AT89C51 Application

AT89C51 In-Circuit Programming

8-Bit
Microcontroller
with Flash

Application
Note

0287C

Microcontroller

This application note illustrates the in­circuit programmability of the Atmel
AT89C51 Flash-based microcontroller.
Guidelines for the addition of in-circuit
programmability to AT89C51 applica­tions are presented along with an appli­cation example and the modifications to
it required to support in-circuit program­ming. A method is then shown by which
the AT89C51 microcontroller in the ap­plication can be reprogrammed re­motely, over a commercial telephone
line. The circuitry described in this appli­cation note supports five volt program­ming only, requiring the use of an
AT89C51-XX-5. The standard AT89C51
requires 12 volts for programming.

The software for this application may be
obtained by downloading from Atmel’s
BBS: [phone].

General Considerations

Circuitry added to support AT89C51 in­circuit programming should appear
transparent to the application when pro­gramming is not taking place.

EA#/VPP must be held high during pro­gramming. In applications which do not
utilize external program memory, this
pin may be permanently strapped to

. Applications utilizing external pro-

V

CC

gram memory require that this pin be
held low during normal operation.

RST must be held active during pro­gramming. A means must be provided
for overriding the application reset cir­cuit, which typically asserts RST only
briefly after power is applied.

PSEN# must be held low during pro­gramming, but must not be driven during
normal operation.

ALE/PROG# is pulsed low during pro­gramming, but must not be driven during
normal operation.

During programming, AT89C51 I/O
ports are used for the application of
mode select, addresses and data, pos­sibly requiring that the controller be iso­lated from the application circuitry. How
this is done is application dependent
and will be addressed here only in gen­eral terms.

Port Used for Input

During programming, the controller
must be isolated from signals sourced
by the application circuitry. A buffer with
three-state outputs might be inserted
between the application circuitry and the
controller, with the buffer outputs three­stated when programming is enabled.
Alternately, a multiplexer might be used
to select between signal sources, with
signals applied to the controller by either
the application circuitry or the program­mer circuitry.

Port Used for Output

No circuit changes are required if the
application circuitry can tolerate the
state changes which occur at the port
during programming. If the prior state of
the application circuitry must be main­tained during programming, a latch
might be inserted between the controller
and the application circuitry. The latch is
enabled during programming, preserv­ing the state of the application circuitry.

An Application Example

The AT89C51 application shown in Fig­ure 1 is an implementation of a moving
display. This application was selected
for its simplicity and ability to show
graphically the results of in-circuit repro­gramming. The text to be displayed is

4-9

programmed into the controller as part of its firmware, and
cannot be changed without reprogramming the device.

The displayed text is presented in one of two modes se­lected by the four-position DIP switch. In the first mode,
one character at a time enters the display from the right
and moves quickly to the left through each element of the
display to its final position in the assembled message. In
the second mode, the message moves through the dis­play, from right to left, with the display acting as a window
onto the message. This mode is familiar as the method
often used in displays of stock prices.

The output consists of four DL1414T, four-digit, 17-seg­ment alphanumeric displays with integral decoders and
drivers. This yields 16 total display elements, each capa­ble of displaying digits 0-9, the upper case alphabet, and
some punctuation characters. The displayable character
codes are ASCII 20H-5FH.

A power-on reset circuit and six megahertz crystal oscilla­tor complete the application. Neither external program
memory nor external data memory is used.

Modifications to the Application to Support
In-Circuit Programming

Figure 2 shows the application modified for in-circuit
programming.

It is assumed that the programmer, when inac tive, will nei­ther drive nor excessively load the application.

Since the application does not use external program
memory, EA#/VPP on the controller is connected to V
This meets the requirement for programming.

The reset circuit has been modified by the addition of two
transistors, which allow RST on the controller to be forced
high by the programmer.

PSEN# and ALE/PROG#, unused in the basic application,
are under the direct control of the programmer.

Programming requires programmer access to all of the
four AT89C51 I/O ports, as documented in the data sheet.
The programmer is connected directly to those controller
pins which are unused by the application, while access to
pins used by the application requires special treatment, as
explained in the following paragraphs.

The least significant four bits of the addr ess gener ated by
the programmer are multiplexed onto port one of the con­troller with the data from the DIP switch. Note that the four
resistors added at the switch are not required in the basic
application, since the AT89C51 provides internal pull-ups
on port one.

During the normal operation of the application, controller
ports zero and two provide data and control signals (re­spectively) to the displays. During programming and pro­gram verification, the programmer asserts control of port

CC

zero and part of port two. The programmer is connected
to ports zero and two without buffering, since, when inac­tive, its presence does not affect the normal operation of
the application.

A transparent latch has been added between port two of
the controller and the display control inputs. The latch
holds the display control signals inactive during program­ming, which eliminates erratic operation of the displays
due to programmer activity on ports zero and two. No iso­lation of the display data inputs is required, since data ap­plied to the inputs is ignored when the control signals are
inactive.

The AT89C51 reset circuit, input multiplexer and output
latch are controlled by a single signal generated by the
programmer. During programming, reset is asserted, the
multiplexer switches inputs, and the latch freezes the dis­play control lines.

To ensure that the display control lines are in a known
state before they are latched, an AT89C51 external inter­rupt is used to allow the programmer to signal the applica­tion before asserting reset. The application firmware re­sponds to the interrupt by displaying a message and de­activating the display control lines.

After programming, when reset is deasserted, the c ontrol­ler ports are high as the latch becomes transparent. Since
the display control inputs are inactive high, the display
contents are not disturbed until the new program writes
the display.

.

Although not essential to this application, it might be im­perative in some applications that the state of the periph­eral circuitry not be disturbed during programming.

The Programmer

The programmer (Figure 3) generates the addresses,
data and control signals necessary to program the
AT89C51 embedded in the application.

The programmer circuitry consists of an AT89C51 and an
RS-232 level translator. The controller runs at 11.0592
megahertz, which allows the serial port to operate at a
number of standard baud rates. A Maxim MAX232 line
driver/receiver produces RS-232 levels at the serial inter­face while requiring only a five volt supply.

Many of the signals generated by the programmer are
connected directly, without buffering, to the AT89C51 in
the application. These signals, when inactive, are not
three-stated, but are pulled high. The AT89C51 has inter­nal pull-ups of approximately three KOhms on ports one,
two and three. Because port zero does not have internal
pull-ups, external pull-ups of ten KOhms have been
added to permit proper operation of program verification
mode. The sample application operates correctly in this
environment. If required for compatibility with an applica-

4-10 Microcontroller

Microcontroller

tion, programmer signals may be buffered with three-state
buffers similar to the 74xx125.

The AT89C51 in the programmer does not utilize external
program or data memory, which would require sacrificing
needed I/O pins. This requires that program code and I/O
buffers be kept small enough to fit in on-chip memory.

Remote Programming Ov er a Commercial
Telephone Line

The programmer and display application described pre­viously are connected to a phone line via a modem at a
remote site. Using a personal computer with a modem, a
user can upload a new program containing a new mes­sage, which is programmed into the AT89C51 embedded
in the application. When programming is complete, the
application executes the new program, which displays the
new message.

Local Station

The local station in the test configuration consists of an
IBM PC AT-class computer connected to a Hayes-com­patible, Prometheus 1200 baud modem. The modem was
selected because it was inexpensive and available. A
faster modem may be used if desired, although once the
file transmission time is reduced below one minute, further
reductions in transmission time do not further reduce con­nect time charges. A possible advantage to higher trans­mission speeds is the automatic error detection and cor­rection available in some high speed modems.

Procomm Plus version 2.01, a commercial data communi­cations package, is used to configure the modem, set up
communications parameters, and establish a link with the
remote modem. Procomm Plus includes a macro lan­guage called ASPECT, which allows the user to write and
compile scripts which implement custom file transfer pro­tocols. A simple ASPECT script was written to read the
contents of a program file and upload it to the remote pro­grammer.

The file transfer protocol (FTP) implemented is a simple
send-and-wait, packet-oriented protocol. The transmit
and receive modes of the FTP are illustrated by the flow­charts in figures 4 and 5, respectively. The transmitter
sends each packet without flow control and waits for a re­sponse. The programmer (the receiver) reads and dis­sects the packet while calculating a checksum. If the cal­culated checksum is valid, the programmer ac knowledges
the packet by sending an ACK. If the checksum is in error,
the programmer negatively acknowledges the packet by
sending a NAK. Upon receipt of an ACK, the transmitter
sends the next packet. If the transmitter receives a NAK,
it resends the same packet. Transmission proceeds in this
manner until the entire file has been transferred.

The programmer might respond to a packet by sending a
CAN, which indicates that a non-recoverable error has oc­curred and that the transmitter should immediately abort
the file transfer. If the programmer fails to respond to a
packet within a limited period of time, the transmitter will
resend the same packet. The transmitter will continue to
resend the same packet until a valid response is received
or until the allowed number of attempts is exceeded, at
which time the file transfer is aborted.

After each packet is received and validated by the pro­grammer, the data contained in the packet is programmed
into the AT89C51 controller in the application. After pro­gramming, the data is read back from the controller and
verified against the received packet data. Successful v eri­fication indicates successful programming, causing the
programmer to send ACK to the transmitter. If program­ming fails, the programmer sends CAN to signal the trans­mitter to abort the file transfer.

The simplicity of the FTP reduces the amount of AT89C51
program memory used in the programmer. The send-and­wait nature of the FTP allows inter-packet delays due to
AT89C51 program and erase times to be easily absorbed.
Support for program verification is transparent, requiring
no explicit command or result codes, or additional data
transfers.

The files which are uploaded to the programmer are cre­ated with the tools in the Intel MCS-51 Software Develop­ment Package for the IBM PC. Included in the package
are the MCS-51 Macro Assembler, MCS-51 Relocator
and Linker, and a useful utility, OH. OH converts an abso­lute 8051 object file to an equivalent ASCII hexadecimal
object file.

The records in the hex file produced by the OH utility
serve, unchanged, as the packets in the FTP described
above; no service fields need to be added. The colon
which begins each record serves as the packet signature
field. The load address field serves as the packet se­quence number. A checksum is provided as the last field
in each record. Since seven-bit ASCII coding is utilized,
the eighth bit of each byte is available to be used for parity
checking.

Because the AT89C51 in the programmer does not utilize
external data memory, necessary packet buffering must
be done using internal RAM. Limited memory precludes
the use of conventional FTPs which utilize packets of 128
bytes and larger. The hex packet format used in this appli­cation limits packet data fields to 16 or fewer entries, re­quiring little memory for buffering.

The ready availability of a utility for creating the packet­ized program file, combined with small packet size and
adequate error checking, makes the hex packet format a
near ideal solution for this application. A disadvantage is

4-11

the use of ASCII, which requires each program data byte
to be expressed as two hex characters. This demands
that nearly twice as many bytes be transferred as might
otherwise be required. This is not a severe limitation, how­ever, since typical file transfer times are less than one
minute. Overall, the simplicity of the custom FTP/hex
packet format implementation outweighs the drawbacks.

Remote Station

The remote station in the test configuration consists of the
display application and programmer circuits, described
previously, connected to a Hayes-compatible,
Prometheus 1200 baud modem. During normal operation,
the application executes its internal program while the mo­dem and programmer monitor the phone line for incoming
calls.

After a call has been detected and a connection estab­lished, the programmer forces the application to suspend
execution of its program. The new program is then down­loaded and programmed into the AT89C51 embedded in
the application. When programming is complete, the ap­plication is allowed to begin execution of its new progr am,
and the programmer returns to monitoring the phone line
for the next call.

The programmer powers up with its programming control
outputs inactive, allowing the application to run normally.
After configuring the modem to answer incoming calls, the
programmer puts itself to sleep. The programmer will not
disturb the application until a new program is to be down­loaded.

The programmer controls the modem by sending ASCII
command strings over the serial interface, to which the
modem responds with Hayes-style ASCII numeric codes.
The software is designed for use with Hayes-compatible
modems, which includes the Prometheus ProModem
1200 used here.

The serial interface, through which the programmer con­nects to the modem, supports two handshaking signals,
DTR and DSR. On power up, the programmer asserts
DTR, to which the modem responds by asserting DSR. If
the modem should fail to respond to any command, in­cluding the command to hang up, the programmer deas­serts DTR, which forces the modem to drop the line.

The modem monitors the phone line while the program­mer sleeps, waiting for an incoming call. When a call is
detected, the modem answers and attempts to establish
communication with the caller. If a connection is estab­lished, the modem sends a code to the programmer, wak­ing it up. The programmer verifies the connect code and
begins polling for a valid packet header.

Incoming packets must arrive fewer than thirty seconds
apart, or the modem drops the line (hangs up) and the
programmer returns to sleep, waiting for the next call. If

the caller hangs up, the thirty second period must expire
before another call will be answered. Calls incoming dur­ing the reset delay period are ignored.

If a valid packet header is received prior to the expiration
of the reset delay period, the programmer will attempt to
read and validate the incoming packet. At any time during
packet reception, an invalid character, parity error or time­out during character reception will cause the partial
packet to be declared invalid and discarded.

Two packet types are defined: data and end-of-file. A data
packet contains five fields in addition to the packet
header, one of which is a variable length data field. The
data field contains program data to be written into the
AT89C51 controller in the application. The load address
field contains the address at which the data is to be writ­ten. The end-of-file packet contains the same fields as the
data packet, except that the data field is empty. This
packet type has special meaning to the programmer, as
explained below.

Any packet which contains an invalid record type, record
length or checksum is invalid. Program data accumulated
during the processing of an invalid packet is discarded.
The programmer sends a NAK to the transmitter to signal
reception of an invalid packet and resumes polling for a
valid packet header.

Receipt of the first valid data packet causes the program­mer to interrupt the application controller. The controller
responds to the interrupt by abandoning execution of its
usual program and displaying a message indicating that
programming is taking place. If this is the first valid data
packet since power was applied or an end-of-file packet
was received, the programmer asserts the control signals
necessary to erase the program memory in the applica­tion controller. The programmer then places the controller
in programming mode.

The first and subsequent valid data packets are dissected
as they are received and the data which they contain is
programmed into the application controller at the address
indicated in the packet load address field. After program­ming, the data is read back from the controller and verified
against the received packet data. Successful verification
indicates that programming was successful, causing the
programmer to send ACK to the transmitter. The program­mer then resumes polling for a valid packet header, sub­ject to the thirty second reset delay.

If programming fails, the programmer sends CAN to sig­nal the transmitter to abort the file transfer. The modem
drops the line and the programmer returns to sleep, wait­ing for the next call. The application controller is left in pro­gramming mode, preventing it from executing the incom­plete or invalid program which it contains.

4-12 Microcontroller