Programmer4.pdf

(482 KB) Pobierz
Microcontroller
AT89S8252 In-System Programming
Introduction
This application note illustrates the in-
system programmability of the Atmel
AT89SXXXX (S-series) microcontrol-
lers. A method is shown by which an
AT89S8252 in an application may be
programmed remotely over a standard
telephone line.
The software for this application note
may be obtained by downloading from:
Atmel BBS (408) 436-4309 or
Website: http://www.atmel.com
A power-on reset circuit and a 6-MHz
crystal complete the application. Neither
external program memory nor external
data memory is used.
Modifications to the Application to
Support In-System Programming
The AT89S8252 microcontroller features
an SPI port, through which on-chip Flash
memory and EEPROM may be pro-
grammed. To program the microcontrol-
ler, RST is held high while commands,
addresses and data are applied to the
SPI port. For command format and tim-
ing requirements, refer to the Atmel
AT89S8252 Microcontroller data sheet.
Figure 2 shows the example application
modified for in-system programming.
The microcontroller reset circuit has
been eliminated and RST is controlled
by the programmer. The absence of a
reset circuit requires that the program-
mer reset the microcontroller when
power is first applied to the application.
An optional connection (SHUTDN) to an
AT89S8252 interrupt input has been pro-
vided to allow the programmer to signal
the microcontroller prior to programming.
The resident firmware responds to the
inter rupt by d ispl ayi ng a m ess age
(“PROGRAMMING”) indicating that pro-
gramming is in progress.
A simple latch, composed of four OR
gates, has been added between the out-
puts of the microcontroller and the dis-
play control inputs. The latch holds the
display control signals inactive when
RST is asserted, eliminating erratic oper-
ation of the displays during program-
ming. No isolation of the display address
or data inputs is required, since these
inputs are ignored by the displays when
the control signals are inactive. After
programming, when RST is deasserted,
the microcontroller I/O ports are high as
Microcontroller
Application
Note
Microcontroller
An Example Application
The application shown in Figure 1 is a
simple implementation of a moving dis-
play. This application was selected for its
simplicity and ability to show graphically
the results of in-system programming.
The text to be displayed is programmed
into the AT89S8252 microcontroller as
part of its firmware, and can be changed
by reprogramming the device.
The displayed text is presented in one of
two modes, selected by a 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 sec-
ond mode, the message moves through
the display, from right to left, with the dis-
play acting as a window onto the mes-
sage. This mode is familiar as the
method often used in displays of stock
prices.
The text is displayed on four DL1414T,
four-element, 17-segment alphanumeric
displays with integral decoders and driv-
ers. This yields 16 total display ele-
ments, each capable of displaying digits
0-9, the upper case alphabet, and punc-
tuation characters. The displayable char-
acter codes are ASCII 20-5F (hexadeci-
mal).
0898A-A–12/97
5-73
the latch becomes transparent. Since the display control
inputs are inactive high, the display contents are not dis-
turbed until the new firmware writes the displays. Although
not essential in this application, it might be imperative in
some applications that the state of the peripheral circuitry
not be disturbed during programming.
Finally, programmer access has been provided to three
AT89S8252 SPI port pins: P1.5/MOSI, P1.6/MISO and
P1.7/SCK. SPI port pin P1.4/SS is not used during pro-
gramming. In the example application, the SPI port pins are
Figure 1.
AT89S8252 Moving Display Application Example
available for use in programming the microcontroller. Appli-
cations which utilize the SPI port pins must be modified by
the addition of circuitry which will isolate the SPI port when
RST is asserted, freeing the pins for use in programming
the microcontroller. Circuitry which is added to support pro-
gramming must appear transparent to the application dur-
ing normal operation.
The code for the modified display application is shown in
Appendix 2.
5-74
Microcontroller
Microcontroller
Figure 2.
AT89S8252 Moving Display Application Modified for In-System Programming
The Programmer
The programmer shown in Figure 3 interfaces with a
modem, from which it receives packetized data. After dis-
secting the data packets, the programmer generates the
signals required to program the data into the AT89S8252
microcontroller in the modified application. Code for the
programmer is shown in Appendix 3.
The programmer circuitry consists of little more than an
Atmel 20-pin AT89C2051 microcontroller and a Maxim
MAX232 line driver/receiver. The microcontroller runs at
11.0592 MHz, which allows the serial port to operate at a
number of standard baud rates. The line driver/receiver
produces RS-232 levels at the modem interface while
requiring only a 5-V power supply. The AT89C2051 micro-
controller does not support external program or data mem-
ory, which requires that program code be kept small
enough to fit into on-chip memory.
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, includ-
ing the command to hang up, the programmer deasserts
DTR, which forces the modem to hang up.
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 programmer code is optimized for use with the U.S.
Robotics Sportster 14,400 baud external modem used in
the test configuration and may require modifications if used
with other modems.
Since a reset circuit is absent from the modified application,
the programmer provides the power-on reset function to the
AT89S8252 microcontroller. The programmer powers up
with RST asserted, resetting the microcontroller. Some
5-75
time later, RST is deasserted under firmware control, allow-
ing the application microcontroller to run normally. When
Figure 3.
AT89S8252 Programmer
programming is required, the programmer again asserts
RST.
During programming, the programmer outputs serial data
on the MOSI pin, synchronized to a software-generated
clock output on the SCK pin. Serial data is input on the
MISO pin, also synchronized to SCK. The maximum fre-
quency of SCK must be less than 1/40th the crystal fre-
quency of the AT89S8252 microcontroller being pro-
grammed, as specified in the AT89S8252 data sheet. The
documented code produces a maximum SCK frequency of
approximately 90 KHz, permitting a minimum AT89S8252
crystal frequency of approximately 3.6 MHz.
Remote Programming Over a Standard
Telephone Line
The programmer and modified application described previ-
ously are connected to a phone line through a modem at a
remote site. Using a personal computer with a modem, a
user can upload code containing a new message, which is
programmed into the AT89S8252 microcontroller in the
application. When programming is complete, the microcon-
troller executes the new firmware, which displays the new
message.
Local Station
The local station in the test configuration consists of an IBM
PC AT-compatible personal computer with a Cardinal
MVPV34ILC 33,600 baud internal modem. Any modem
may be used, as long as it is compatible with the data com-
munications software and matches the data rate and error
correction protocols of the modem at the remote site.
Procomm Plus for Windows, version 3.0, a commercial
data communications package, is used to configure the
modem, set up communications parameters, and establish
a link with the remote modem. Procomm Plus includes a
macro language called ASPECT, which allows the user to
write and compile scripts which implement custom file
transfer protocols. A simple ASPECT script was written to
read the contents of a code file and upload it to the remote
programmer. The ASPECT script is shown in Appendix 4.
The file transfer protocol (FTP) implemented is a simple
send-and-wait, packet-oriented protocol. The FTP transmit
and receive modes are diagrammed in the flowcharts in fig-
ures 4 and 5, respectively. The computer sends each
packet without flow control and waits for a response. The
programmer may acknowledge the packet by sending an
ACK or may negatively acknowledge the packet by sending
a NAK. Upon receipt of an ACK, the computer sends the
next packet. If the clone 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
occurred and that the computer should immediately abort
the file transfer. If the programmer fails to respond to a
5-76
Microcontroller
Microcontroller
packet within a limited period of time, the computer will
resend the same packet. The computer 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.
The send-and-wait nature of the FTP allows the time
required for the programmer to program the packet data
into the application microcontroller to be easily absorbed.
Programming verification requires no explicit command or
result codes, or additional data transfers. The program-
mer’s response to a packet reflects the result of the pro-
gramming verification operation performed by the program-
mer: ACK indicates success, CAN indicates failure.
Hexadecimal object file format (Intel hex) was chosen as
the format of the files to be uploaded to the programmer.
The records in a hex file serve, unchanged, as the packets
in the FTP described above; no service fields need to be
added. The fields in Intel hex file records are shown in
Appendix 1. The colon which begins each record serves as
the packet signature field. The load address field serves as
the packet sequence number. A checksum is provided as
the last field in each record. Since 7-bit ASCII coding is uti-
lized, the eighth bit of each byte is available to be used for
parity checking.
Since the AT89C2051 microcontroller in the programmer
does not utilize external data memory, necessary packet
buffering must be done using internal RAM. Limited mem-
ory precludes the use of conventional FTPs which utilize
packets of 128 bytes or more. The hex packet format used
in this application limits packet data fields to 16 or fewer
entries, requiring little memory for buffering.
A disadvantage of the hex packet format is 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 other-
wise be required. This is not a severe limitation, however,
since typical file transfer times are on the order of a few
seconds.
Remote Station
The remote station in the test configuration consists of the
pr og r amm er a nd mo di fi ed ap pli c ati on , p re v iou sl y
described, connected to a U.S. Robotics Sportster 14,400-
baud external modem.
After power is applied, the programmer resets the
AT89S8252 microcontroller in the application, and then
sets its control outputs inactive, allowing the application to
run normally. The programmer configures the modem to
answer incoming calls and puts itself to sleep. While the
programmer sleeps, the modem monitors the phone line,
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 established, the modem
sends a connect code to the programmer, waking it up. The
programmer verifies the connect code and begins polling
for a valid packet header. Invalid connect codes are
ignored.
Incoming packets must arrive fewer than 30 seconds apart,
or the modem hangs up and the programmer returns to
sleep, waiting for the next call. If the caller hangs up, the
30-second period must expire before another call will be
answered. Calls incoming during 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 application
microcontroller. The load address field contains the
address at which the data is to be written. 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 computer to signal recep-
tion 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 microcontroller. The micro-
controller responds to the interrupt by abandoning its usual
routine and displaying a message (“PROGRAMMING”)
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 place the microcontroller into
programming mode.
The first and subsequent valid data packets are dissected
as they are received and the data which they contain is pro-
grammed into the application microcontroller at the address
indicated in the packet load address field. After program-
ming, the data is read back from the microcontroller and
verified against the received packet data. If programming
was successful, the programmer sends ACK to the com-
puter. The programmer then resumes polling for a valid
packet header, subject to the thirty second reset delay.
If programming fails, the programmer sends CAN to signal
the computer to abort the file transfer. The modem hangs
up and the programmer returns to sleep, waiting for the
next call. The application microcontroller is left in program-
5-77

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin