AN1576
APPLICATION NOTE
IN-APPLICATION PROGRAMMING (IAP) DRIVERS
FOR ST7 HDFLASH OR XFLASH MCUs
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 board: not only the physical channel (I/Os, SPI, UART, USB, CAN,..) for re-
ceiving the new data, but also the protocol (Commands, Status, Data structure,..) can be user
specific.
The principle of the IAP process (See Application Note AN1575 for further details) is to exe-
cute from a protected memory area, Flash Sector 0, a firmware module that reprograms the
remaining memory area: In order to help you develop you own reprogramming firmware,
STMicroelectronics provides generic IAP drivers that can be used whatever the protocol or
physical layer.
This application note presents these two generic In-Application Programming drivers: one for
HDFLASH based MCUs and one for XFLASH based devices.
The architecture and the software interface as well as some practical examples are presented
for each of these two drivers.
AN1576/0203
1/15
1
XFLASH DRIVER
1 XFLASH DRIVER
The XFlash driver is a software which can be compiled 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
function is provided,
since it can be emulated by writing 0xFF in a memory block.
The driver code is approximately 256 bytes in size, this may vary slightly depending 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 memory. Both hardware keys must always be
loaded externally (via I/O ports, SCI, etc...). This security feature prevents any wrongful ac-
cess after a program counter corruption.
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
points to the start address of the new data to be programmed
–
Flash
points to the XFLASH start address area where the new data is to be programmed
–
ByteNb
is the number of bytes to be programmed
The ByteNb can take a value of up to 256 even though the XFLASH itself is programmed 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 allows user specific functions to be executed while an XFlashWriteBlock
function is executing. Writing 256 bytes requires several tenths of a millisecond during which
time you may have to manage some tasks: A typical example is to refresh 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 firmware in Flash Sector 0, the XflashWriteBlock 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 ST72F264 MCU.
It is important to note these 27 bytes are used only during the XFlashWriteBlock 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
Stack
Page 0: 0xFFh
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:
s
s
s
s
Reset and initialization routines
Basic user interface
Reprogramming routines (On external Interrupt)
Reprogrammable software module in sector 1
Figure 2. Example Flowchart
Begin
Initialization
Endless loop in
sector1
External Interrupt
Load new program
from external EEPROM to buffer
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
Linux开发
京公网安备 11010802033920号
Copyright © 2005-2026 EEWORLD.com.cn, Inc. All rights reserved
电子工程世界
