Many members of the Maxim 8051-based microcontroller family support in-system programming via a commonly available RS-232 serial interface. In-system programming means that the program and/or data memory can be modified without disassembling the embedded system to physically replace memory. With an emphasis on ease-of-use and versatility, this feature adds a number of very valuable features in any embedded design:
- Allows hardware to be assembled and stocked at the factory and software-customized right before shipment,
- Eliminates high cost of disassembling units in field when software updates are required,
- Allows for software upgrades in physically inaccessible locations,
- Accesses dedicated configuration and status registers, and
- Enables the loading of software into secure microcontrollers with memory encryption.
Devices with this feature include:
Secure Microcontroller Modules: DS2250, DS2250T, DS2251T, DS2252T, DS5000, DS5000T
Secure Microprocessors: DS5000FP, DS5001FP, DS5002FP, DS5002FPM
High-Speed Secure Microprocessor: DS5250
Networking Microprocessor: DS80C400
Ultra-High-Speed Flash Microcontrollers: DS89C430, DS89C450
The bootstrap loader is invoked by taking one or more external device pins to a specified state. When activated, the device begins execution of loader software from a dedicated ROM inside the device. Upon receipt of a carriage return character, the serial port performs an autobaud function and synchronizes itself to the host's baud rate. Communication between the host (usually a PC) and the target is via the common RS-232 interface found on most PCs, eliminating the need for expensive custom hardware. The protocol used by the bootloader is simple and consists of one or more ASCII character commands with associated status messages and file transfer routines. Communications can be performed using the free Microcontroller Tool Kit communications software from Maxim or with any serial communications tool.
Most of these devices also support in-application programming, allowing the device to modify its program memory under control of the application software. In this way the design can perform on-the-fly software updates while still performing its primary function. Details are presented in the datasheet or user's guide for that particular device.
This document is intended to be a supplement to information provided in the data sheet and/or user's guides for a particular device. Please reference these documents as needed while reading this application note.
The bootstrap loader is invoked by taking one or more pins to the specified state as shown in Table 1
. At this time application software execution is terminated and program control is transferred to the internal bootstrap ROM. Be sure to check the appropriate errata sheet to see if there are any errata associated with bootstrap loader activation.
Table 1. Bootstrap Loader Stimuli
||P2.7 AND P2.6
||Unconnected or logic 1
||Unconnected or logic 1
The physical connection and method of invoking the bootloader varies slightly between device families, but contains the same basic elements. If connecting to a PC, an RS-232 to CMOS level translator is required as shown to interface the communication and control signals between the host and target microcontroller. Any comparable RS-232 translator may be substituted for the one shown. The following figures shown use the DTR signal of the microcontroller as a load/run mode select.
Several of the designs use a bus buffer with tri-state outputs. When DTR is active (low state), it enables the buffers to turn on, driving the multiple signals that activate the bootloader. This bus buffer is generically referred to in the schematics as an "HC/AC125," because any similar device of any logic families will do, such as 74HC125, 54HC125, 74AC125, 74LS125, etc. These devices are common and should be available from any supplier of general-purpose logic such as Motorola, Fairchild Semiconductor, Toshiba, ST Microelectronics, and many others.
For other devices a single signal activates the bootloader, so this buffer is not needed. In this case the DTR signal can be connected directly to the activation pin on the target microcontroller.
Figure 1. Physical connection, DS89C430/DS89C450-based designs.
Figure 2. Physical connection, DS5250 and DS5001/DS5002FP-based designs.
Figure 3. Physical connection, DS5000-based designs.
The bootloader uses the clock source attached to the XTAL1/XTAL2 pins as its time base. If a crystal is used, it must meet the recommendations (resonance in fundamental mode, parallel AT-cut, amount of load capacitance, etc.) listed in the datasheet for that device. Because the bootloader relies on internal timers for the autobaud measurements, it has a few restrictions on the range of frequencies compatible with the bootloader. Please consult the User's Guide for your particular device for the range of clock frequencies that are compatible with the bootloader.
After the bootstrap loader has been activated, the microcontroller will poll the serial port, looking for a carriage return (0Dh) character in the eight data bit, no parity, one stop bit (8-N-1) format. The bootstrap loader software measures the length of the high and low spaces within that character to determine the baud rate of the host system. This autobaud feature allows the bootstrap loader to communicate with a number of host systems without being limited to a fixed baud rate.
Once the bootstrap loader has been invoked and the baud rate calculated, the device will transmit a sign-on banner identifying the device. Then the device will display a prompt character and wait for commands. Again, the command set varies between device families, but they are usually single ASCII characters and will always include versions of load, verify, and erase memory commands. Consult the specific device user guide for a command listing.
The simple bootstrap loader interface permits several ways to communicate between the PC and target
microcontroller. The simplest is to use the Microcontroller Tool Kit (MTK2) from Maxim. MTK2 is a PC utility for communicating with the ROM/bootstrap loader of most Maxim microcontrollers. It is a highfeatured front-end, simplifying the task of configuring the target and uploading and downloading code and configuring special functions.
A main window allows the user to type commands directly to the target microcontroller. Many commands supported by the target loader can be entered directly from the main window of MTK2. Special support is provided for filerelated commands that require special communication protocols.
Figure 4. Microcontroller Tool Kit.
It is also possible to use a simple terminal emulator such as Procomm Plus or Hyperterminal for communication if the target microcontroller is a based on the DS5000FP, DS5001FP, DS5002FP, or DS80C400. Other 8051-based microcontrollers from Maxim utilize an interactive loading protocol that requires a protocol-aware application.
Debugging Communication Problems
The following are a list of the most common problems encountered while communicating with the microcontroller via the bootstrap loader.
Wrong Clock Frequency
The bootstrap loader may be unable to autobaud if the device is clocked at the wrong frequency. Check the user's guide for the supported frequencies. If frequency-dependent problems are suspected, it is highly recommended that any bootloader problems be debugged using an 11.0592MHz crystal. This is a very standard microcontroller operating frequency and will generate most standard baud rates.
Other Applications Interfering with COM Port
Background applications can be intentionally or unintentionally interfering with the selected COM port on the PC. Check the Task Manager for any possible conflict sources.
PC Baud Rate Too Fast for Selected Operating Frequency
At slow operating frequencies (below approximately 5MHz) the device may not be able to autobaud to high baud
rates or may be unable to process large files without overrunning its buffer. Reduce the baud rate and try again.
Microcontroller Not Operating
It is possible that the observed failure is not with the bootloader but rather the microcontroller itself. The following is a short diagnostic checklist to troubleshoot system-level problems.
- Is power being supplied to all the power pins of the device at the correct voltage? Be sure to probe the actual pin of the microcontroller, not traces on the board, for the most accurate reading.
- If the active-low EA pin is held low do the address pins toggle? On many devices holding active-low EA low places the device into external access mode, which forces the device to fetch instructions from the external bus. Although it is not immediately evident if the device is generating the right addresses, the presence of address bus activity indicates the microcontroller is in an operational state.
- On certain devices the ALE pin toggles by default. Is it active? Does it match the expected frequency? On most devices, the ALE signal will oscillate at a division of the oscillator frequency.
- Does the device have sufficient decoupling capacitance? Most Maxim microcontrollers operate at higher internal clock rates than their traditional counterparts. Drop-in designs or upgrades may require additional capacitance to accommodate the performance increase.
Obsolete Version of Microcontroller Tool Kit
Are you using the latest version of the Microcontroller Tool Kit software?
Download the latest Microcontroller Tool Kit
Have you checked the appropriate errata sheet for any relevant errata? Although rare, it is possible for the
bootstrap loader to deviate from published specifications on certain device revisions.
Cable Too Long
Excessive cable length between the host computer and the target computer can degrade signal quality. There is no definite rule for how long the cable length should be, but standard operating principles such as using shielded cable, and keeping away from noise sources such as motors and Tesla coils should help. The effect of long cables can be reduced by decreasing the baud rate in use.