ST AN1576 Application note

AN1576

APPLICATION NOTE

IN-APPLICATION PROGRAMMING (IAP) DRIVERS

FOR ST7 HDFLASH OR XFLASH M CUs

by Microcontroller Division Applications

INTRODUCTION

The In-Application Programming (IAP) architecture defined by STMicroelectronics gives a
large flexibility in terms of the communication method used to (re)program a ST7 FLASH Mi­crocontroller on bo ard: no t only the physica l chan nel (I/O s, SPI, U ART, USB, C AN,..) for re­ceiving the new data, but also the protocol (Commands, Status, Data structure,..) can be user
specific.

The principle of the IAP pr ocess ( See Application N ote AN1575 for further d etails) i s to e xe­cute from a p rotected m e mory area, Flash S ecto r 0, a firm ware mo dule tha t reprogram s t he
remaining memory area: In order to help you dev elop you own reprogramming firmware,
STMicro elect ronics provid es gener ic IAP dr ivers that ca n be us ed what ever the p rotoc ol or
physical layer.

This application note presents these two generic In- Appl ication Programming drivers: one for
HDFLASH based MCUs and one for XFLA SH based devices.

The architecture and the software interfac e as well as s ome practi cal examples are presented
for each of these two drivers.

AN1576/0203 1/15

1

XFLASH DRIVER

1 XFLASH DRIVER

The XFlash driver is a softw are which can be comp iled using either C -Metrowerks or C­COSMIC and supports all memory models.

The driver is composed of 2 files: XFlash.c and XFlash.h to be included in the project. It pro­vides RASS_Disable, and XFlashWriteBlock functions. No

Sector Erase

since it can be emulated by writing 0xFF in a memory block.
The driver code i s approxim ately 256 by tes in size, this may vary slightly de pending on the

compilation.

1.1 DRIVER FUNCTIONS

1.1.1 RASS_Disable

void RASS_Disable(unsigned char key1,unsigned char key2)

This function disables the RASS protection to allow write access to XFLASH sectors 1 & 2, if
the two user variables key1 and key2 have the correct values: 0x56 and 0xAE.

To increase the reliability of the system, the software sequence which writes the hardware
keys should not be stored in the program mem ory. Both hardware keys must always be
loaded ext ernal ly (via I/O ports, SC I, e tc ...). Thi s s ec urity fe atu re p reve nts a ny w ron gfu l ac ­cess after a program counter corruption.

function is provided,

1.1.2 XFlashWriteBlock

unsigned char XFlashWriteBlock( unsigned char *Buffer, unsigned int Flash, unsigned char ByteNb )

This function performs write operations with the following parameters:

–

Buffer

–

Flash

–

ByteNb

points to the start address of the new data to be programmed

points to the XFLASH start address area where the new data is to be programmed

is the number of bytes to be programmed

The ByteNb can take a val ue of up to 256 ev en tho ugh the XF LA SH itself i s progr ammed in
rows of 32 bytes max: The XFLASH driver handles the iterative loops automatically in cases
where ByteNb is greater than 32.

The function returns a status: 0 means a failed operation, while a 1 means a successful oper­ation.

2/15

2

XFLASH DRIVER

1.1.3 User functions

The XFlash driver allow s use r specific functi ons to be ex ecuted w hile an XF lashW riteBl ock
function is executing. Writing 256 bytes requires several tenths of a millisecond during which
time you may have to manage some tasks: A typic al example is to refres h the watchdog , in
order to avoid a Reset during XFlash reprogramming.

For this purpose the driver provides 1 function named UserWhileWriteBlock that you have to
define in your firmware (take care to not use the RAM area with the driver variables).

Finally, the Interrupts are reenabled (RIM assembler instruction) by the driver before the exe­cution of the UserWhileWrite function.

1.2 DRIVER ARCHITECTURE

1.2.1 Driver principle

When called by the user firm ware in Flash Sec tor 0, the Xf lashWrite Block executes the fol­lowing sequence:

– Load the RAM Page 0 with a programming algorithm
– Execute this programming algorithm from RAM
– Return to the user firmware in Flash Sector 0, just after the XflashWriteBlock instruction.
At this point the RAM area used by the programming algorithm is released and is available to

the user firmware.

1.2.2 Memory management

The programming algorithm requires 20 bytes and is positioned at the end of RAM Page 0.
In addition, 7 bytes in RAM Page 0 are reserved for the IAP driver internal variables.
The location of the 27 bytes (algorithm plus variables) is defined in the Xflash.h file by the pa-

rameter STACK_END: The location is then 0xE4h-0xFFh for a S T72F264 M CU.
It is important to note these 27 bytes ar e used only during the XFlash WriteBlo ck execution:

You can still use this area in his application firmware (except in the UserWhileWriteBlock func­tion) as long as he accepts they are overwritten during the IAP process.

3/15

XFLASH DRIVER

Figure 1. RAM usage with XFLASH driver: ST72F264 example

New data to be programmed

Page 0: 0xE4h

Programming algorithm

Page 0: 0xF8h

Driver internal variables

Page 0: 0xFFh

Stack

1.2.3 Interrupts

All the interrupt sources are disabled (SIM assembler instruction) by the XFlash driver.

4/15

XFLASH DRIVER

1.3 IMPLEMENTATION GUIDELINES

An example is used to describe some generic guidelines you have to follow when developing
an application with IAP capability. It includes all the modules you need for an application with
IAP:

■ Reset and initialization routines

■ Basic user interface

■ Reprogramming routines (On external Interrupt)

■ Reprogrammable software module in sector 1

Figure 2. Example Flowchart

Begin

Initialization

External Interrupt

Load new program

from external EEPROM to buffer

Endless loop in sector1

Start programming phase

Software Reset

1.3.1 Project Configuration

1.3.1.1 Driver Configuration

The first step is to correctly configure the stack position in the Xflash.h file. This parameter is
defined by the variable STACK_END. The XFlash driver uses this value to address its internal
variables located at the top of RAM Page 0.

1.3.1.2 Program Memory

Special attention must be paid to the fact that some routines have to be executed from Sector
0 to ensure reliable operations.

Therefore pragmas have to be defined in such a way that Sector 0 includes: the XFlash driver,
the Reset, Initialization and UserWhileWriteBlock routines as well as any library routines
(Delay loops,..) needed for the reprogramming process.

5/15