This document describes the USB bootloader functionality as well as the USB protocol to efficiently perform operations on the on-chip Flash memory. Additional
information on the AT89C5132 product can be found in the AT89C5132 datasheet and
the AT89C5132 errata sheet available on the Atmel web site, www.atmel.com.
The bootloader software (binary file) currently used for production is available from the
Atmel web site.
USB
Microcontrollers
AT89C5132
USB Bootloader
Bootloader RevisionPurpose of ModificationsDate
Revisions 1.6.2 and higherFirst release3/25/2003
Rev. 4256A–USB–06/03
1
Functional
Description
The AT89C5132 USB Bootloader facilitates In-System Programming (ISP) and In-Application Programming (IAP) .
In-System Programming
Capability
In-Application
Programming or SelfProgramming Capability
In-System Programming allows the user to program or reprogram the microcontroller
on-chip Flash memory without removing it from the system and without the need of a
pre-programmed application.
The USB bootloader can manage a communication with a host through the USB bus. It
can also access and perform requested operations on the on-chip Flash memory.
IAP allows the reprogramming of the microcontroller on-chip Flash memory without
removing it from the system and while the embedded application is running.
The USB bootloader contains some Application Programming Interface routines named
API routines allowing IAP by using the user’s firmware.
Block DiagramThis section describes the different parts of the USB bootloader. Figure 1 shows the on-
chip bootloader and IAP processes.
Figure 1. Bootloader Process Description
External host via the
USB Protocol
Communication
ISP Communication
Management
IAP
User Call
Management
On-chip
User
Application
Flash Memory
Management
Flash
Memory
2
AT89C5132
4256A–USB–06/03
AT89C5132
ISP Communication
Management
The purpose of this process is to manage the communication and its protocol between
the on-chip bootloader and an external device (host). The on-chip bootloader implements a USB protocol (see Section “Protocol”, page 10). This process translates serial
communication frames (USB) into Flash memory accesses (read, write, erase...).
User Call ManagementSeveral Application Program Interface (API) calls are available to the application pro-
gram to selectively erase and program Flash pages. All calls are made through a
common interface (API calls) included in the bootloader. The purpose of this process is
to translate the application request into internal Flash memory operations.
Flash Memory ManagementThis process manages low level accesses to the Flash memory (performs read and
write accesses).
Bootloader Configuration
Configuration and
Manufacturer Information
The following table lists Configuration and Manufacturer byte information used by the
bootloader. This information can be accessed through a set of API or ISP commands.
Tab le 1 . Configuration and Manufacturer Byte Information
MnemonicDescriptionDefault Value
BSBBoot Status ByteFFh
SBVSoftware Boot VectorFOh
SSBSoftware Security ByteFFh
Mapping and Default Value of
Hardware Security Byte
EBExtra ByteFFh
Manufacturer58h
Id1: Family CodeD7h
Id2: Product NameF7h
Id3: Product RevisionDFh
The 4 MSB of the Hardware Byte can be read/written by software (this area is called
Fuse bits). The 4 LSB can only be read by software and written by hardware using parallel programmer devices, this area is called Lock bits.
Tab le 2. Hardware Byte Information
Bit PositionMnemonicDefault Value Description
7X2BUTo start in x1 mode
6BLJBPTo map the boot area in code area between F000h-FFFFh
5–U
4–U
3reservedU
2LB2P
To lock the chip (see datasheet)1LB1U
4256A–USB–06/03
0LB0U
Note:U: Unprogrammed = 1
P: Program = 0
3
SecurityThe bootloader has Software Security Byte (SSB) to protect itself from user access or
ISP access.
The Software Security Byte (SSB) protects from ISP accesses. The command ’Program
Software Security Bit’ can only write a higher priority level. There are three levels of
security:
•Level 0: NO_SECURITY (FFh)
This is the default level.
From level 0, one can write level 1 or level 2.
•Level 1: WRITE_SECURITY (FEh)
In this level it is impossible to write in the Flash memory.
The Bootloader returns an err_WRITE status.
From level 1, one can write only level 2.
•Level 2: RD_WR_SECURITY (FCh)
Level 2 forbids all read and write accesses to/from the Flash memory.
The Bootloader returns an err_WRITE or an err_VENDOR status.
Only a full chip erase command can reset the software security bits.
Tab le 3 . Security Levels
Level 0Level 1Level 2
FlashAny access allowedRead only access allowedAll access not allowed
Fuse bitAny access allowedRead only access allowedAll access not allowed
SSBAny access allowedWrite level2 allowedRead only access allowed
Manufacturer info Read only access allowedRead only access allowedRead only access allowed
Bootloader infoRead only access allowedRead only access allowedRead only access allowed
Erase blockAllowedNot allowedNot allowed
Full chip eraseAllowedAllowedAllowed
Blank CheckAllowedAllowedAllowed
4
AT89C5132
4256A–USB–06/03
AT89C5132
Software Boot VectorThe Software Boot Vector (SBV) forces the execution of a user bootloader starting at
address [SBV]00h in the application area (FM0).
The way to start this user bootloader is described in Section “Bootloader Configuration”.
USB Bootloader
User Bootloader
Application
FM0
[SBV]00h
FLIP Software ProgramFLIP is a PC software program running under Windows
that supports all Atmel Flash microcontrollers and USB protocol communication media.
This free software program is available from the Atmel web site.
FM1
®
9x/Me/2000/XP and LINUX
®
4256A–USB–06/03
5
In-System
Programming
The ISP allows the user to program or reprogram the microcontroller’s on-chip Flash
memory through the serial line without removing it from the system and without the need
of a pre-programmed application.
This section describes how to start the UART bootloader and the higher level protocol
over the serial line.
Bootloader ExecutionAs internal C51 code space is limited to 64K bytes, some mechanisms are implemented
to allow boot memory to be mapped in the code space for execution at addresses F000h
to FFFFh. The boot memory is enabled by setting the ENBOOT bit in AUXR1. The three
ways to set this bit are detailed below.
Software Boot MappingThe software way to set ENBOOT consists in writing to AUXR1 from the user’s soft-
ware. This enables bootloader or API routines execution.
Hardware Condition Boot
Mapping
Programmed Condition Boot
Mapping
The hardware condition is based on the ISP# pin. When driving this pin to low level, the
chip reset sets ENBOOT and forces the reset vector to F000h instead of 0000h in order
to execute the bootloader software.
As shown in Figure 2, the hardware condition always allows In-System recovery when
user’s memory has been corrupted.
The programmed condition is based on the Bootloader Jump Bit (BLJB) in HSB. As
shown in Figure 2, this bit is programmed (by hardware or software programming
mode), the chip reset set ENBOOT and forces the reset vector to F000h instead of
0000h, in order to execute the bootloader software.
6
AT89C5132
4256A–USB–06/03
Figure 2. Boot Process Algorithm
AT89C5132
RESET
Hard Cond?
ISP# = L?
HardwareSoftware
Standard Init
ENBOOT = 0
PC = 0000h
FCON = F0h
ProcessProcess
User’s
Application
Prog Cond?
BLJB = P?
Prog Cond Init
ENBOOT = 1
PC = F000h
FCON = F0h
Hard Init?
FCON = 00h?
User Boot?
SBV < F0h?
User’s
Bootloader
Hard Cond Init
ENBOOT = 1
PC = F000h
FCON = 00h
Atmel’s
Bootloader
4256A–USB–06/03
7
Physical LayerThe USB norm specifies all the transfers over the USB line. The USB specification also
includes several CLASS and SUB-CLASS specifications. These stand-alone documents
are used by the manufacturer to implement a USB link between a PC and a device supporting the In-System Programming. Mostly, the USB specification is implemented by
hardware (automatic reply, handshakes, timings, ...) and the USB Classes and SubClasses are implemented by software at a data level.
Figure 3. USB Bus Topography
Downstream Transfer: OUT
Upstream Transfer: IN
48 MHz Frequency Autogeneration
PC driver
PC application
USB line
application (Device)
PC (Host)
The USB used to transmit information has the following configuration:
•USB DFU using the Default Control Endpoint only (endpoint 0) with a 32 bytes
length.
•48 MHz for USB controller: frequency auto-detection performed by the bootloader.
The following table shows the allowed frequencies compatible with the USB bootloader
48 MHz auto-generation.
12 MHz16 MHz20 MHz
X1 - X2OKOKOK
Device Driver/API
Firmware
8
AT89C5132
4256A–USB–06/03
Figure 4. 48 MHz Frequency Auto-generation
AT89C5132
MAIN
No
Resume
Detected?
Yes
No
Yes
USB Connected?
Suspend/Resume
Yes
Configure PLL for
Frequency X
Configure Timer 0
SOF Detected?
No
Timer 0 Overflow?
Yes
No
4256A–USB–06/03
Change Frequency
USB Scheduler
9
Protocol
Device Firmware Upgrade
Introduction
Device Firmware Upgrade is the mechanism for accomplishing the task of upgrading the
device firmware. Any class of USB device can exploit this capability by supporting the
requirements specified in this document.
Because it is impractical for a device to concurrently perform both DFU operations and
its normal run-time activities, those normal activities must cease for the duration of the
DFU operations. Doing so means that the device must change its operating mode; i.e., a
printer is not
a printer while it is undergoing a firmware upgrade; it is a PROM program-
mer. However, a device that supports DFU is not capable of changing its mode of
operation on its own. External (human or host operating system) intervention is
required.
DFU Specific RequestsIn addition of the USB standard requests, 7 DFU class-specific requests are employed
to accomplish the upgrade operations, see the following table.
8iInterface100hIndex of the String descriptor for this interface
The device doesn’t use a class specific protocol
on this interface
(1)
11
4256A–USB–06/03
Note:1. Alternate settings can be used by an application to access additional memory seg-
ments. In this case, it is suggested that each alternate setting employs a string
descriptor to indicate the target memory segment; e.g., “EEPROM”. Details concerning other possible uses of alternate settings are beyond the scope of this document.
However, their use is intentionally not restricted because it is anticipated that implementers will devise additional creative uses for alternate settings.
DFU Functional Descriptor
Tab le 8 . DFU Functional Descriptor
OffsetFieldSizeValueDescription
0bLength107hSize of this descriptor, in bytes
1bDescriptorType121hDFU FUNCTIONAL descriptor type
DFU Attributes:
bit 7..3 : reserved
2bmAttributes1Bit mask
3wDetachTimeOut2Number
bit 2: device is able to communicate via USB after Manifestation phase
1 = yes, 0 = no, must see bus reset
bit 1: bitCanUpload : upload capable 1 = yes, 0 = no
bit 0: bitCanDnload : download capable 1 = yes, 0 = no
Time in milliseconds that the device will wait after receipt of the
DFU_DETACH request.
If this time elapses without a USB reset, the device will terminate the
Reconfiguration phase and revert back to normal operation. This
represents the maximum time that the device can wait (depending on its
timers, ...). The Host may specify a shorter timeout in the DFU_DETACH
request.
5wTransferSize2Number
Command DescriptionThis protocol allows to:
•Initiate the communication
•Program the Flash Data
•Read the Flash Data
•Program Configuration Information
•Read Configuration and Manufacturer Information
•Erase the Flash
•Start the application
Overview of the protocol is detailed in Appendix-A.
Maximum number of bytes that the device can accept per control-write
transaction
12
AT89C5132
4256A–USB–06/03
AT89C5132
Device Status
Get StatusThe Host employs the DFU_GETSTATUS request to facilitate synchronization with the
device. This status gives information on the execution of the previous request: in
progress/OK/Fail/...
The device responds to the DFU_GETSTATUS request with a payload packet containing the following data:
Tab le 9 . DFU_GETSTATUS Response
OffsetFieldSizeValueDescription
0bStatus1NumberAn indication of the status resulting from the execution of the most recent request.
Minimum time in milliseconds that the host should wait before sending a subsequent
1bwPollTimeOut3Number
4bState1Number
5iString1IndexIndex of status description in string table.
DFU_GETSTATUS. The purpose of this field is to allow the device to dynamically adjust
the amount of time that the device expects the host to wait between the status phase of
the next DFU_DNLOAD and the subsequent solicitation of the device’s status via
DFU_GETSTATUS.
An indication of the state that the device is going to enter immediately following
transmission of this response.
Tab le 1 0. bStatus Values
StatusValueDescription
OK0x00No error condition is present
errTARGET0x01File is not targeted for use by this device
errFILE0x02File is for this device but fails some vendor-specific verification test
errADDRESS0x08Cannot program memory due to received address that is out of range
errNOTDONE0x09Received DFU_DNLOAD with wLength = 0, but device does not think it has all the data yet
errFIRMWARE0x0ADevice’s firmware is corrupted. It cannot return to run-time operations
errVENDOR0x0BiString indicates a vendor-specific error
errUSBR0x0CDevice detected unexpected USB reset signaling
4256A–USB–06/03
13
Tab le 1 0. bStatus Values (Continued)
StatusValueDescription
errPOR0x0DDevice detected unexpected power on reset
errUNKNOWN0x0ESomething went wrong, but the device does not know what it was
errSTALLEDPK0x0FDevice stalled an unexpected request
Tab le 11. bState Values
StateValueDescription
appIDLE0Device is running its normal application
appDETACH1
dfuIDLE2Device is operating in the DFU mode and is waiting for requests
dfuDNLOAD-SYNC3Device has received a block and is waiting for the Host to solicit the status via DFU_GETSTATUS
dfuDNBUSY4Device is programming a control-write block into its non-volatile memories
dfuDNLOAD-IDLE5Device is processing a download operation. Expecting DFU_DNLOAD requests
dfuMANIFEST-SYNC6
dfuMANIFEST7Device is in the Manifestation phase.
dfuMANIFEST-WAIT-RESET8Device has programmed its memories and is waiting for a USB reset or a power on reset.
dfuUPLOAD-IDLE9The device is processing an upload operation. Expecting DFU_UPLOAD requests.
dfuERROR10An error has occurred. Awaiting the DFU_CLRSTATUS request.
Device is running its normal application, has received the DFU_DETACH request, and is waiting for a
USB reset
Device has received the final block of firmware from the Host and is waiting for receipt of
DFU_GETSTATUS to begin the Manifestation phase
or
device has completed the Manifestation phase and is waiting for receipt of DFU_GETSTATUS.
Clear StatusAny time the device detects an error and reports an error indication status to the host in
the response to a DFU_GETSTATUS request, it enters the dfuERROR state. The
device cannot transition from the dfuERROR state, after reporting any error status, until
after it has received a DFU_CLRSTATUS request. Upon receipt of DFU_CLRSTATUS,
the device sets a status of OK and transitions to the dfuIDLE state. Only then it is able to
transition to other states.
bmRequestTypebRequestwValuewIndexwLengthData
0010 0001bDFU_CLRSTATUS (4)ZeroInterface (4)0None
Device StateThis request solicits a report about the state of the device. The state reported is the cur-
rent state of the device with no change in state upon transmission of the response. The
values specified in the bState field are identical to those reported in DFU_GETSTATUS.
bmRequestTypebRequestwValuewIndexwLengthData
1010 0001bDFU_GETSTATE (5)ZeroInterface (4)1State
14
AT89C5132
4256A–USB–06/03
AT89C5132
DFU_ABORT RequestThe DFU_ABORT request enables the device to exit from certain states and return to
the DFU_IDLE state. The device sets the OK status on receipt of this request. For more
information, see the corresponding state transition summary.
bmRequestTypebRequestwValuewIndexwLengthData
1010 0001bDFU_ABORT (6)ZeroInterface (4)0None
Programming the FlashThe firmware image is downloaded via control-write transfers initiated by the
DFU_DNLOAD class-specific request. The host sends between bMaxPacketSize0 andwTransferSize bytes to the device in a control-write transfer. Following each downloaded block, the host solicits the device status with the DFU_GETSTATUS request.
As described in the USB DFU Specification, Firmware images for specific devices are,
by definition, vendor specific. It is therefore required that target addresses, record sizes,
and all other information relative to supporting an upgrade are encapsulated within the
firmware image file. It is the responsibility of the device manufacturer and the firmware
developer to ensure that their devices can consume these encapsulated data. With the
exception of the DFU file suffix, the content of the firmware image file is irrelevant to the
host.
Firmware image:
•32 bytes: Command
•X bytes: X is the number of byte (00h) added before the first significative byte of the
firmware. The X number is calculated to align the beginning of the firmware with the
flash page. X = start_address [32]. For example, if the start address is 00AFh
(175d), X = 175 [32] = 15.
•The firmware
•The DFU Suffix on 16 Bytes
Tab le 1 2. DFU File Suffix
OffsetFieldSizeValueDescription
- 0dwCRC4NumberThe CRC of the entire file, excluding dwCRC
- 4bLength116The length of this DFU suffix including dwCRC
5 : 44h
- 5ucDfuSignature3
- 8bcdDFU2
- 10idVendor2ID
- 12idProduct2ID
- 14bcdDevice2BCD
6 : 46h
7 : 55h
BCD
0100h
The unique DFU signature field
DFU specification number
The vendor ID associated with this file. Either FFFFh or must match
device’s vendor ID
The product ID associated with this file. Either FFFFf or must match
device’s product ID
The release number of the device associated with this file. Either
FFFFh or a BCD firmware release or version number
The write command is 6 bytes long. In order to reach the USB specification of the Control type transfers, the write command is completed with 26 (=32-6) non-significant
bytes. The total length of the command is then 32 bytes, which is the length of the
Default Control Endpoint.
FirmwareThe firmware can now be downloaded to the device. In order to be in accordance with
the Flash page size (128 bytes), X non-significant bytes are added before the first byte
to program. The X number is calculated to align the beginning of the firmware with the
Flash page. X = start_address [32]. For example, if the start address is 00AFh (175d), X
= 175 [32] = 15.
DFU SuffixThe DFU suffix of 16 bytes are added just after the last byte to program. This suffix is
reserved for future use.
Figure 5. Example of Firmware Download Zero Length DFU_DNLOAD Request
SETUP
OUT
OUT
DFU_DNLOAD
Prog_Start + (EP0 fifo length - 6) x 00h
X offset bytes + Firmware Packet 1
16
OUT
OUT
IN
AT89C5132
Firmware Packet 2
Firmware Packet n + DFU suffix
ZLP
The Host sends a DFU_DNLOAD request with the wLength field cleared to 0 to the
device to indicate that it has completed transferring the firmware image file. This is the
final payload packet of a download operation.
This operation should be preceded by a Long Jump address specification using the corresponding Flash command.
4256A–USB–06/03
AT89C5132
Answers from BootloaderAfter each program request, the Host can request the device state and status by send-
ing a DFU_GETSTATUS message.
If the device status indicates an error, the host can send a DFU_CLRSTATUS request
to the device.
Reading the FlashThe flow described below allows the user to read data in the Flash memory. A blank
check command on the Flash memory is possible with this flow.
This operation is performed in 2 steps:
1. DFU_DNLOAD request with the read command (6 bytes)
2. DFU_UPLOAD request which correspond to the immediate previous command.
First Request from HostThe Host sends a DFU Download request with a Display command in the data field.
Second Request from HostThe Host sends a DFU Upload request.
Answers from the DeviceThe device send to the Host the firmware from the specified start address to the end
address.
SETUP
DFU_UPLOAD
4256A–USB–06/03
INFirmware Packet 1
IN
IN
OUT
Firmware Packet 2
Firmware Packet n
ZLP
17
Answers from the Device to a
Blank Check Command
The Host controller send a GET_STATUS request to the device. Once internal blank
check has been completed, the device sends its status.
•If the device status is “OK”:
the device memory is then blank and the device waits the next Host request.
•If the device status is “
the device memory is not blank. The device waits for an DFU_UPLOAD request to
send the first address where the byte is not 0xFF.
errCHECK_ERASED”:
18
AT89C5132
4256A–USB–06/03
AT89C5132
Programming
Configuration
Information
The flow described below allows the user to program Configuration Information regarding the bootloader functionality.
•Boot Process Configuration:
–BSB
–SBV
–Fuse bits (BLJB, X2) (see Section “Mapping and Default Value of Hardware
Security Byte”, page 3)
Ensure that the Program Fuse bit command programs the 4 Fuse bits at the same time.
Request from HostTo start the programming operation, the Host sends DFU_DNLOAD request with the
Answers from BootloaderThe device has two possible answers to a DFU_GETSTATUS request:
•If the chip is protected from program access, a “err_WRITE” status is returned to the
Host.
•Otherwise, the device status is “OK“.
The full chip erase is always executed whatever the Software Security Byte value is.
22
AT89C5132
4256A–USB–06/03
AT89C5132
Starting the ApplicationThe flow described below allows to start the application directly from the bootloader
upon a specific command reception.
Two options are possible:
•Start the application with a reset pulse generation (using watchdog).
When the device receives this command the watchdog is enabled and the
bootloader enters a waiting loop until the watchdog resets the device.
Ensure that if an external reset chip is used the reset pulse in output may be wrong
and in this case the reset sequence is not correctly executed.
•Start the application without reset
A jump at the address 0000h is used to start the application without reset.
To start the application, the Host sends a DFU_DNLOAD request with the specified
application start type in the data field (3 or 5 bytes).
This request is immediately followed by a second DFU_DNLOAD request with no data
field to start the application with one of the two options.
Answer from BootloaderNo answer is returned by the device.
DFU_UPLOAD
Jump option (3 or 5 bytes)
ZLP
DFU_UPLOAD
4256A–USB–06/03
23
In-Application
Programming/SelfProgramming
The IAP allows to reprogram the microcontroller on-chip Flash memory without removing it from the system and while the embedded application is running.
The user application can call Application Programming Interface (API) routines allowing
IAP. These API are executed by the bootloader.
To call the corresponding API, the user must use a set of Flash_api routines which can
be linked with the application.
Example of Flash_api routines are available on the Atmel web site:
C Flash Drivers for the AT89C5132
The flash_api routines on the package work only with the USB bootloader.
The flash_api routines are listed in APPENDIX-B.
API Call
ProcessThe application selects an API by setting the 4 variables available when the flash_api
library is linked to the application.
These four variables are located in RAM at fixed address:
•api_command: 1Ch
•api_value: 1Dh
•api_dph: 1Eh
•api_dpl: 1Fh
All calls are made through a common interface “USER_CALL” at the address FFF0h.
The jump at the USER_CALL must be done by LCALL instruction to be able to comeback in the application.
Before jump at the USER_CALL, the bit ENBOOT in AUXR1 register must be set.
ConstraintsThe interrupts are not disabled by the bootloader.
Interrupts must be disabled by user prior to jump to the USER_CALL, then re-enabled
when returning.
The user must take care of hardware watchdog before launching a Flash operation.
For more information regarding the Flash writing time see the AT89C5132 datasheet.
24
AT89C5132
4256A–USB–06/03
API CommandsSeveral types of APIs are available:
•Read/Program Flash memory
•Read Configuration and Manufacturer Information
•Program Configuration Information
•Erase Flash
•Start bootloader
Read/Program Flash MemoryTo read the Flash memory the bootloader is not involved.
For more details on these routines see the AT89C5132 Datasheet, section “Program/Code Memory”.
Two routines are available to program the Flash:
–__api_wr_code_byte
–__api_wr_code_page
•The application program load the column latches of the Flash then call the
__api_wr_code_byte or __api_wr_code_page see datasheet, section
“Program/Code Memory
•Parameter settings
”.
AT89C5132
API Nameapi_commandapi_dphapi_dplapi_value
__api_wr_code_byte
__api_wr_code_page
0Dh–––
•Instruction: LCALL FFF0h.
Note:No special resources are used by the bootloader during this operation
4256A–USB–06/03
25
Read Configuration and
Manufacturer Information
•Parameter settings
API Nameapi_commandapi_dphapi_dplapi_value
__api_rd_HSB08h–00hreturn HSB
__api_rd_BSB05h–00hreturn BSB
__api_rd_SBV05h–01hreturn SBV
__api_rd_SSB05h–05hreturn SSB
__api_rd_EB05h–06hreturn EB
__api_rd_manufacturer05h–30h
__api_rd_device_id105h–31hreturn id1
__api_rd_device_id205h–60hreturn id2
__api_rd_device_id305h–61hreturn id3
__api_rd_bootloader_version0Eh–00hreturn value
return
manufacturer id
•Instruction: LCALL FFF0h.
•At the complete API execution by the bootloader, the value to read is in the
api_value variable.
Note:No special resources are used by the bootloader during this operation
26
AT89C5132
4256A–USB–06/03
AT89C5132
Program Configuration
Information
•Parameter settings
API Nameapi_commandapi_dphapi_dplapi_value
__api_clr_BLJB07h––
__api_set_BLJB07h––HSB & BFh
__api_clr_X207h––
__api_set_X207h––HSB & 7Fh
__api_wr_BSB04h–00hvalue to write
__api_wr_SBV04h–01hvalue to write
__api_wr_SSB04h–05hvalue to write
__api_wr_EB04h–06hvalue to write
•instruction: LCALL FFF0h.
Notes: 1. Refer to the AT89C5132 datasheet for information on Write operation Timing.
2. No special resources are used by the bootloader during these operations.
Erasing the FlashThe AT89C5132 Flash memory is divided into four blocks:
Block 0: from address 0000h to 1FFFh (64 pages)
(HSB & BFh) |
40h
(HSB & 7Fh) |
80h
Block 1: from address 2000h to 3FFFh (64 pages)
Block 2: from address 4000h to 7FFFh (128 pages)
Block 3: from address 8000h to FFFFh (256 pages)
•Parameter settings
API Nameapi_commandapi_dphapi_dplapi_value
__api_erase_block000h00h––
__api_erase_block100h20h–
__api_erase_block200h40h–
__api_erase_block300h80h–
•Instruction: LCALL FFF0h.
Note:1. Refer to the AT89C5132 datasheet for information on Write operation Timing, then
multiply this timing by the number of pages.
2. No special resources are used by the bootloader during these operations.
Starting the BootloaderThis routine allows to start at the beginning of the bootloader as after a reset. After call-
ing this routine the regular boot process is performed and the communication must be
opened before any action.
1150 East Cheyenne Mtn. Blvd.
Colorado Springs, CO 80906
Tel: 1(719) 576-3300
Fax: 1(719) 540-1759
Biometrics/Imaging/Hi-Rel MPU/
High Speed Converters/RF Datacom
Avenue de Rochepleine
BP 123
38521 Saint-Egreve Cedex, France
Tel: (33) 4-76-58-30-00
Fax: (33) 4-76-58-34-80
e-mail
literature@atmel.com
Web Site
http://www.atmel.com
Disclaimer: Atmel Corporation makes no warranty for the use of its products, other than those expressly contained in the Company’s standard
warranty which is detailed in Atmel’s Terms and Conditions located on the Company’s web site. The Company assumes no responsibility for any
errors which may appear in this document, reserves the right to change devices or specifications detailed herein at any time without notice, and
does not make any commitment to update the information contained herein. No licenses to patents or other intellectual property of Atmel are
granted by the Company in connection with the sale of Atmel products, expressly or by implication. Atmel’s products are not authorized for use
as critical components in life support devices or systems.