Features
• Protocol
– USB Used as a Physical Layer
– Device Firmware Upgrade Class Compliant
– Auto-Frequency Detection
• In-System Programming
– Read/Write Flash Memory
– Read Device ID
– Full-chip Erase
– Read/Write Configuration Bytes
– Security Setting from ISP Command
– Remote Application Start Command
• In-Application Programming/Self-Programming
– Read/Write Flash Memory
– Read Device ID
– Block Erase
– Read/Write Configuration Bytes
– Bootloader Start
Description
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 Revision Purpose of Modifications Date
Revisions 1.6.2 and higher First release 3/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 Diagram This 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 Management Several 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 Management This 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
Mnemonic Description Default Value
BSB Boot Status Byte FFh
SBV Software Boot Vector FOh
SSB Software Security Byte FFh
Mapping and Default Value of Hardware Security Byte
EB Extra Byte FFh
Manufacturer 58h
Id1: Family Code D7h
Id2: Product Name F7h
Id3: Product Revision DFh
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 Position Mnemonic Default Value Description
7 X2B U To start in x1 mode
6 BLJB P To map the boot area in code area between F000h-FFFFh
5– U
4– U
3 reserved U
2LB2 P
To lock the chip (see datasheet)1LB1 U
4256A–USB–06/03
0LB0 U
Note: U: Unprogrammed = 1
P: Program = 0
3
Security The 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 0 Level 1 Level 2
Flash Any access allowed Read only access allowed All access not allowed
Fuse bit Any access allowed Read only access allowed All access not allowed
BSB & SBV & EB Any access allowed Any access allowed Any access allowed
SSB Any access allowed Write level2 allowed Read only access allowed
Manufacturer info Read only access allowed Read only access allowed Read only access allowed
Bootloader info Read only access allowed Read only access allowed Read only access allowed
Erase block Allowed Not allowed Not allowed
Full chip erase Allowed Allowed Allowed
Blank Check Allowed Allowed Allowed
4
AT89C5132
4256A–USB–06/03
AT89C5132
Software Boot Vector The 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 Program FLIP 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 Execution As 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 Mapping The 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
Process Process
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 Layer The 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 MHz 16 MHz 20 MHz
X1 - X2 OK OK OK
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 Requests In addition of the USB standard requests, 7 DFU class-specific requests are employed
to accomplish the upgrade operations, see the following table.
Tab le 4 . DFU Class-specific Requests
bmRequestType bRequest wValue wIndex wLength Data
0010 0001b DFU_DETACH (0) wTimeout Interface (4) Zero none
0010 0001b DFU_DNLOAD (1) wBlock Interface (4) Length Firmware
1010 0001b DFU_UPLOAD (2) wBlock Interface (4) Length Firmware
1010 0001b DFU_GETSTATUS (3) Zero Interface (4) 6 Status
0010 0001b DFU_CLRSTATUS (4) Zero Interface (4) Zero none
1010 0001b DFU_GETSTATE (5) Zero Interface (4) 1 State
0010 0001b DFU_ABORT (6) Zero Interface (4) Zero none
DFU Descriptors set The device exports the DFU descriptor set, which contains:
• A DFU device descriptor
• A single configuration descriptor
• A single interface descriptor (including descriptors for alternate settings, if present)
• A single functional descriptor
DFU Device Descriptor This descriptor is only present in the DFU mode descriptor set. The DFU class code is
reported in the bDeviceClass field of this descriptor.
Tab le 5 . USB Parameters
Parameter ATMEL – AT89C5132 bootloader
Vendor ID 0x03EB
Product ID 0x2FFF
Release Number 0x0000
10
AT89C5132
4256A–USB–06/03
Loading...