5-11

AT89C51 In-Circuit Programming

This application note illustrates the in-cir-cui t programmabi l i ty of the AtmelAT89C51 Flash-based microcontroller.Guidelines for the addition of in-circuitprogrammability to AT89C51 applica-tions are presented along with an appli-cation example and the modifications toit required to support in-circuit program-ming. A method is then shown by whichthe AT89C51 microcontroller in theappl icat ion can be reprogrammedremotely, over a commercial telephoneline. The circuitry described in this appli-cation note supports five volt program-ming only, requir ing the use of anAT89C51-XX-5. The standard AT89C51requires 12 volts for programming.

The software for this application may beobtained by downloading from Atmel’sBBS: (408) 436-4309.

General ConsiderationsCircuitry added to support AT89C51 in-circuit programming should appeartransparent to the application when pro-gramming is not taking place.

EA/VPP must be held high during pro-gramming. In applications which do notutilize external program memory, this pinmay be permanently strapped to VCC.Applications utilizing external programmemory require that this pin be held lowduring normal operation.

RST must be held active during pro-gramming. A means must be providedfor overriding the application reset cir-cuit, which typically asserts RST onlybriefly after power is applied.

PSEN must be held low during program-ming, but must not be driven during nor-mal operation.

ALE/PROG is pulsed low during pro-gramming, but must not be driven duringnormal operation.

During programming, AT89C51 I/O portsare used for the application of modeselect, addresses and data, possiblyrequiring that the controller be isolatedfrom the application circuitry. How this isdone is application dependent and willbe addressed here only in generalterms.

Port Used for InputDuring programming, the controller mustbe isolated from signals sourced by theapplication circuitry. A buffer with three-state outputs might be inserted betweenthe application circuitry and the control-ler, with the buffer outputs three-statedwhen programming is enabled. Alter-nately, a multiplexer might be used toselect between signal sources, with sig-nals applied to the controller by eitherthe application circuitry or the program-mer circuitry.

Port Used for OutputNo circuit changes are required if theapplication circuitry can tolerate the statechanges which occur at the port duringprogramming. If the prior state of theapplication circuitry must be maintainedduring programming, a latch might beinserted between the controller and theapplication circuitry. The latch is enabledduring programming, preserving thestate of the application circuitry.

An Application ExampleThe AT89C51 application shown in Fig-ure 1 is an implementation of a movingdisplay. This application was selected forits simplicity and ability to show graphi-cally the results of in-circuit reprogram-ming. The text to be displayed is pro-grammed into the controller as part of itsfirmware, and cannot be changed with-out reprogramming the device.

0287D-B–9/97

8-Bit Microcontroller with Flash

Application Note

Microcontroller5-12

The displayed text is presented in one of two modesselected by the four-position DIP switch. In the first mode,one character at a time enters the display from the rightand moves quickly to the left through each element of thedisplay to its final position in the assembled message. Inthe second mode, the message moves through the display,from right to left, with the display acting as a window ontothe message. This mode is familiar as the method oftenused in displays of stock prices.

The output consists of four DL1414T, four-digit, 17-seg-ment alphanumeric displays with integral decoders anddrivers. This yields 16 total display elements, each capableof displaying digits 0-9, the upper case alphabet, and somepunctuation characters. The displayable character codesare ASCII 20H-5FH.

A power-on reset circuit and a 6-MHz crystal oscillatorcomplete the application. Neither external program memorynor external data memory is used.

Modifications to the Application to Support In-Circuit ProgrammingFigure 2 shows the application modified for in-circuitprogramming.

It is assumed that the programmer, when inactive, will nei-ther drive nor excessively load the application.

Since the application does not use external program mem-ory, EA/VPP on the controller is connected to VCC. Thismeets the requirement for programming.

The reset circuit has been modified by the addition of twotransistors, which allow RST on the controller to be forcedhigh by the programmer.

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

Programming requires programmer access to all of the fourAT89C51 I/O ports, as documented in the data sheet. Theprogrammer is connected directly to those controller pinswhich are unused by the application, while access to pinsused by the application requires special treatment, asexplained in the following paragraphs.

The least significant four bits of the address generated bythe programmer are multiplexed onto port one of the con-troller with the data from the DIP switch. Note that the fourresistors added at the switch are not required in the basicapplication, since the AT89C51 provides internal pull-upson port one.

During the normal operation of the application, controllerports zero and two provide data and control signals(respectively) to the displays. During programming and pro-gram verification, the programmer asserts control of portzero and part of port two. The programmer is connected toports zero and two without buffering, since, when inactive,its presence does not affect the normal operation of theapplication.

A transparent latch has been added between port two ofthe controller and the display control inputs. The latch holdsthe display control signals inactive during programming,which eliminates erratic operation of the displays due toprogrammer activity on ports zero and two. No isolation ofthe display data inputs is required, since data applied to theinputs is ignored when the control signals are inactive.

The AT89C51 reset circuit, input multiplexer and outputlatch are controlled by a single signal generated by the pro-grammer. During programming, reset is asserted, the multi-plexer switches inputs, and the latch freezes the displaycontrol lines.

To ensure that the display control lines are in a known statebefore they are latched, an AT89C51 external interrupt isused to allow the programmer to signal the applicationbefore asserting reset. The application firmware respondsto the interrupt by displaying a message and deactivatingthe display control lines.

After programming, when reset is deasserted, the controllerports are high as the latch becomes transparent. Since thedisplay control inputs are inactive high, the display contentsare not disturbed until the new program writes the display.

Although not essential to this application, it might be imper-ative in some applications that the state of the peripheralcircuitry not be disturbed during programming.

The ProgrammerThe programmer (Figure 3) generates the addresses, dataand control signals necessary to program the AT89C51embedded in the application.

The programmer circuitry consists of an AT89C51 and anRS-232 level translator. The controller runs at 11.0592MHz, which allows the serial port to operate at a number ofstandard baud rates. A Maxim MAX232 line driver/receiverproduces RS-232 levels at the serial interface while requir-ing only a five volt supply.

Many of the signals generated by the programmer are con-nected directly, without buffering, to the AT89C51 in theapplication. These signals, when inactive, are not three-stated, but are pulled high. The AT89C51 has internal pull-ups of approximately three Kohms on ports one, two andthree. Because port zero does not have internal pull-ups,external pull-ups of ten Kohms have been added to permitproper operation of program verification mode. The sampleapplication operates correctly in this environment. Ifrequired for compatibility with an application, programmersignals may be buffered with three-state buffers similar tothe 74xx125.

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

Microcontroller

5-13

Remote Programming Over a Commercial Telephone LineThe programmer and display application described previ-ously are connected to a phone line via a modem at aremote site. Using a personal computer with a modem, auser can upload a new program containing a new mes-sage, which is programmed into the AT89C51 embedded inthe application. When programming is complete, the appli-cation executes the new program, which displays the newmessage.

Local StationThe local station in the test configuration consists of an IBMPC AT-class computer connected to a Hayes-compatible,Prometheus 1200 baud modem. The modem was selectedbecause it was inexpensive and available. A faster modemmay be used if desired, although once the file transmissiontime is reduced below one minute, further reductions intransmission time do not further reduce connect timecharges. A possible advantage to higher transmissionspeeds is the automatic error detection and correctionavailable in some high speed modems.

Procomm Plus version 2.01, a commercial data communi-cations package, is used to configure the modem, set upcommunications parameters, and establish a link with theremote modem. Procomm Plus includes a macro languagecalled ASPECT, which allows the user to write and compilescripts which implement custom file transfer protocols. Asimple ASPECT script was written to read the contents of aprogram file and upload it to the remote programmer.

The file transfer protocol (FTP) implemented is a simplesend-and-wait, packet-oriented protocol. The transmit andreceive modes of the FTP are illustrated by the flowchartsin figures 4 and 5, respectively. The transmitter sends eachpacket without flow control and waits for a response. Theprogrammer (the receiver) reads and dissects the packetwhile calculating a checksum. If the calculated checksum isvalid, the programmer acknowledges the packet by send-ing an ACK. If the checksum is in error, the programmernegatively acknowledges the packet by sending a NAK.Upon receipt of an ACK, the transmitter sends the nextpacket. If the transmitter receives a NAK, it resends thesame packet. Transmission proceeds in this manner untilthe entire file has been transferred.

The programmer might respond to a packet by sending aCAN, which indicates that a non-recoverable error hasoccurred and that the transmitter should immediately abortthe file transfer. If the programmer fails to respond to apacket within a limited period of time, the transmitter willresend the same packet. The transmitter will continue toresend the same packet until a valid response is receivedor until the allowed number of attempts is exceeded, atwhich time the file transfer is aborted.

After each packet is received and validated by the pro-grammer, the data contained in the packet is programmedinto the AT89C51 controller in the application. After pro-gramming, the data is read back from the controller andverified against the received packet data. Successful verifi-cation indicates successful programming, causing the pro-grammer to send ACK to the transmitter. If programmingfails, the programmer sends CAN to signal the transmitterto abort the file transfer.

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

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 arethe MCS-51 Macro Assembler, MCS-51 Relocator andLinker, and a useful utility, OH. OH converts an absolute8051 object file to an equivalent ASCII hexadecimal objectfile.

The records in the hex file produced by the OH utility serve,unchanged, as the packets in the FTP described above; noservice fields need to be added. The colon which beginseach record serves as the packet signature field. The loadaddress field serves as the packet sequence number. Achecksum is provided as the last field in each record. Sinceseven-bit ASCII coding is utilized, the eighth bit of eachbyte is available to be used for parity checking.

Because the AT89C51 in the programmer does not utilizeexternal data memory, necessary packet buffering must bedone using internal RAM. Limited memory precludes theuse of conventional FTPs which utilize packets of 128bytes and larger. The hex packet format used in this appli-cation limits packet data fields to 16 or fewer entries, requir-ing little memory for buffering.

The ready availability of a utility for creating the packetizedprogram file, combined with small packet size and ade-quate error checking, makes the hex packet format a nearideal solution for this application. A disadvantage is the useof ASCII, which requires each program data byte to beexpressed as two hex characters. This demands thatnearly 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 less than one minute.Overall, the simplicity of the custom FTP/hex packet formatimplementation outweighs the drawbacks.

Remote StationThe remote station in the test configuration consists of thedisplay application and programmer circuits, described pre-viously, connected to a Hayes-compatible, Prometheus

Microcontroller5-14

1200 baud modem. During normal operation, the applica-tion executes its internal program while the modem andprogrammer monitor the phone line for incoming calls.

After a call has been detected and a connection estab-lished, the programmer forces the application to suspendexecution of its program. The new program is then down-loaded and programmed into the AT89C51 embedded inthe 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 linefor the next call.

The programmer powers up with its programming controloutputs inactive, allowing the application to run normally.After configuring the modem to answer incoming calls, theprogrammer puts itself to sleep. The programmer will notdisturb the application until a new program is to be down-loaded.

The programmer controls the modem by sending ASCIIcommand strings over the serial interface, to which themodem responds with Hayes-style ASCII numeric codes.The software is designed for use with Hayes-compatiblemodems, which includes the Prometheus ProModem 1200used 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 assertsDTR, to which the modem responds by asserting DSR. Ifthe modem should fail to respond to any command, includ-ing the command to hang up, the programmer deassertsDTR, which forces the modem to drop the line.

The modem monitors the phone line while the programmersleeps, waiting for an incoming call. When a call isdetected, the modem answers and attempts to establishcommunication 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 andbegins polling for a valid packet header.

Incoming packets must arrive fewer than thirty secondsapart, or the modem drops the line (hangs up) and the pro-grammer returns to sleep, waiting for the next call. If thecaller hangs up, the thirty second period must expire beforeanother call will be answered. Calls incoming during thereset delay period are ignored.

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

Two packet types are defined: data and end-of-file. A datapacket contains five fields in addition to the packet header,one of which is a variable length data field. The data fieldcontains program data to be written into the AT89C51 con-

troller in the application. The load address field contains theaddress at which the data is to be written. The end-of-filepacket contains the same fields as the data packet, exceptthat the data field is empty. This packet type has specialmeaning to the programmer, as explained below.

Any packet which contains an invalid record type, recordlength or checksum is invalid. Program data accumulatedduring the processing of an invalid packet is discarded. Theprogrammer sends a NAK to the transmitter to signalreception of an invalid packet and resumes polling for avalid packet header.

Receipt of the first valid data packet causes the program-mer to interrupt the application controller. The controllerresponds to the interrupt by abandoning execution of itsusual program and displaying a message indicating thatprogramming is taking place. If this is the first valid datapacket since power was applied or an end-of-file packetwas received, the programmer asserts the control signalsnecessary to erase the program memory in the applicationcontroller. The programmer then places the controller inprogramming mode.

The first and subsequent valid data packets are dissectedas 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 verifiedagainst the received packet data. Successful verificationindicates that programming was successful, causing theprogrammer to send ACK to the transmitter. The program-mer then resumes polling for a valid packet header, subjectto the thirty second reset delay.

If programming fails, the programmer sends CAN to signalthe transmitter to abort the file transfer. The modem dropsthe line and the programmer returns to sleep, waiting forthe next call. The application controller is left in program-ming mode, preventing it from executing the incomplete orinvalid program which it contains.

It is important to note that invalid packets are NEVER pro-grammed into the application controller. To do so wouldrequire that the program memory in the controller be com-pletely erased before the error could be corrected, causingthe non-recoverable loss of all previous program data.

Upon receipt of an end-of-file packet, the programmerreturns its control outputs to the inactive, power on state,allowing the application controller to begin execution of thenew program. The programmer then resumes polling for avalid packet header, subject to the thirty second resetdelay.

If a valid packet is received prior to the expiration of thethirty second delay, another programming cycle begins,which can only be terminated by the reception of a validend-of-file packet.

Microcontroller

5-15

If the reset delay expires prior to the reception of a validend-of-file packet, the modem will drop the line and the pro-grammer will return to sleep, waiting for the next call. In thiscase, the application controller is left in programmingmode, preventing it from executing its program. To returnthe application to normal operation, another call must bereceived, and a valid program file uploaded, terminated byan end-of-file packet.

Setting Up the HardwareLocal StationConnect the IBM PC to the ProModem 1200 through one ofthe system COM ports. Connect the modem to an analogtelephone line and set the modem switches as indicatedbelow.

Remote StationConnect the display application/programmer to the secondProModem 1200 through the programmer serial port. Con-nect the modem to an analog telephone line and set themodem switches as indicated below.

Turn the modem on and apply power to the display applica-tion/programmer. The application will begin executing itsprogram, if it contains one. The programmer will initializethe modem, as shown by the activity on the modem statusindicators.

Installing and Configuring Procomm Plus, Version 2.01Install Procomm Plus as instructed in the User Manual.When prompted to specify the modem in use, select‘Prometheus ProModem 1200’ from the list.

Run Procomm Plus and create a dialing directory entry forthe remote station. The baud rate must be set to 1200, par-ity to EVEN, number of data bits to 7, number of stop bits to1, plex to HALF.

Enter the Setup utility (ALT-S). Select ’PROTOCOLOPTIONS’, then ’EXTERNAL PROTOCOL OPTIONS’ fromthe menus and modify the entry for ’EXTERNAL PROTO-COL 1’ as indicated below.

EXTERNAL PROTOCOL 1: A - NAME: <any name>B - TYPE: ASPECT C - UPLOAD COMMAND: ATX.ASX

Note: ’ATX.ASX.’ is the filename of the compiled ASPECT script to be associated with External Protocol 1.

Save the changes and exit the Setup utility.

Creating a Hex FileThe hex files which are uploaded to the programmer arecreated with the tools in the Intel MCS-51 Software Devel-opment Package for the IBM PC. In the example below, the8051 assembler source file is called ’TEST.ASM’.

Assemble the source file ’TEST.ASM’ and create the objectfile ’TEST.OBJ’:

ASM51 TEST.ASM

Link and locate the object file ’TEST.OBJ’ and create theabsolute object file ’TEST.ABS’:

RL51 TEST.OBJ TO TEST.ABS

Convert the absolute object file ’TEST.ABS’ to the hex file’TEST.HEX’:

OH TEST.ABS TO TEST.HEX

The resulting file, ’TEST.HEX’ is ready to be uploaded.

Note: ASM51 is version 2.3; RL51 is version 3.1; OH is version 1.1.

Uploading a Hex FileRun Procomm Plus and use the proper dialing directoryentry to dial the remote station.

After the connection with the remote station is established,press the ’PgUp’ key and select ’1’ (External Protocol 1)from the menu of upload protocols. This will execute theASPECT script associated with External Protocol 1.

When prompted, enter the name of the file to be uploaded,including the extension and path, if required.

When the upload is complete, press ALT-H to hang up andALT-X to exit Procomm Plus and return to DOS.

Switch settings:

1

234

567

89

10

ON

ONOFFON

OFFONOFF

OFFOFF

OFF

Switch settings:

123

456

789

10

ONONON

OFFONON

ONOFFOFF

OFF

Microcontroller5-16

Figure 1. AT89C51 Moving Display Application Example

D0D1D2D3D4D5D6

A0A1

WR

DL1414T

U2

89

101121

12

54

D0D1D2D3D4D5D6

A0A1

WR

DL1414T

U3

89

101121

12

54

P2.0P2.1P2.2P2.3P2.4P2.5P2.6P2.7

D0D1D2D3D4D5D6

A0A1

WR

DL1414T

U4

89

101121

12

54

D0D1D2D3D4D5D6

A0A1

WR

DL1414T

U5

89

101121

12

54

2122232425262728

P0.0P0.1P0.2P0.3P0.4P0.5P0.6P0.7

3938373635343332

PSENALE/PROG

P3.6/WRP3.7/RD

2930

1617

AT89C51

P3.0/RXDP3.1/TXDP3.2/INT0P3.3/INT1P3.4/T0P3.5/T1

P1.0P1.1P1.2P1.3P1.4P1.5P1.6P1.7

12345678

8765

1234

101112131415

U1

EA/VPP

XTAL1

XTAL2

RST

31

19

18

9

C3

30 pF

C2

30 pFR18.2 K

C110 uF

VCC

Note: 0.1 uF bypass caps on all ICs.

SW DIP-4

S1

3

3

3

3

+

Y16 MHz

Microcontroller

5-17

Figure 2. AT89C51 Moving Display Application Modified for In-Circuit Programming

Microcontroller5-18

Figure 3. AT89C51 Programmer

Microcontroller

5-19

Figure 4. FTP Transmit Mode

Microcontroller5-20

Figure 5. FTP Receive Mode

Microcontroller

5-21

Appendix I: Intel Hex File DefinitionHexadecimal object file format (Intel hex) is produced bymost 80C51 assembler products.

Each record in the file contains the following fields:

<:><rec length><load address><rec type><data><check-sum>

The colon is the record header.

The record length field consists of two hex digits, and rep-resents the number of entries in the data field. OH outputsrecords containing 16 or fewer data field entries.

The load address field consists of four hex digits, and indi-cates the absolute address at which the data in the datafield is to be loaded.

The record type field consists of two hex digits, which arealways zero in data records.

The data field contains from one to 16 pairs of hex digits.

The last two hex digits are a checksum on the recordlength, load address, record type, and data fields. The sumof the binary equivalents of these fields and the checksumitself is zero.

Each record in the file is terminated by a carriage returnand line feed.

A type one record marks the end of the file. The recordalways contains the following value: ’:00000001FF’.