Rainbow Electronics AT89C5132 User Manual

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 proto­col 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-Appli­cation Programming (IAP) .

In-System Programming Capability

In-Application
Programming or Self­Programming 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 imple­ments 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 par­allel 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 sup­porting the In-System Programming. Mostly, the USB specification is implemented by
hardware (automatic reply, handshakes, timings, ...) and the USB Classes and Sub­Classes are implemented by software at a data level.

Figure 3. USB Bus Topography

Downstream Transfer: OUT

Upstream Transfer: IN

48 MHz Frequency Auto­generation

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