Rainbow Electronics АТ89С51 - Manual (Page 4)

Microcontroller
5-14
1200 baud modem. During normal operation, the applica-
tion executes its internal program while the modem 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 appli-
cation is allowed to begin execution of its new program,
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, includ-
ing the command to hang up, the programmer deasserts
DTR, which forces the modem to drop the line.
The modem monitors the phone line while the programmer
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 pro-
grammer 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 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 AT89C51 con-
troller in the application. 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 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 application
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 pro-
grammed into the application controller at the address indi-
cated in the packet load address field. After programming,
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, subject
to the thirty second reset delay.
If programming fails, the programmer sends CAN to signal
the transmitter to abort the file transfer. The modem drops
the line and the programmer returns to sleep, waiting for
the next call. The application controller is left in program-
ming mode, preventing it from executing the incomplete or
invalid program which it contains.
It is important to note that invalid packets are NEVER pro-
grammed into the application controller. To do so would
require that the program memory in the controller be com-
pletely erased before the error could be corrected, causing
the non-recoverable loss of all previous program data.
Upon receipt of an end-of-file packet, the programmer
returns its control outputs to the inactive, power on state,
allowing the application controller to begin execution of the
new program. The programmer then resumes polling for a
valid packet header, subject to the thirty second reset
delay.
If a valid packet is received prior to the expiration of the
thirty second delay, another programming cycle begins,
which can only be terminated by the reception of a valid
end-of-file packet.