飞思卡尔关于Bootloader的设计

Implement UART Boot-loader On Coldfire V1 Products

Paul Zhang, Freescale Shanghai. (paul.zhang@https://www.360docs.net/doc/c614042481.html,)

Boot-loader is commonly needed when designing such an embedded system which requires frequent firmware upgrade in the field or via remote. Most of Freescale’s flash based microcontrollers are capable to do flash-programming in the application and on-the-fly. The newly released Coldfire V1 core 32-bit MCU is no exception. This article is aimed at revealing some implementation details to design a boot-loader via conventional UART data port. We’ll use the 1st released V1 part

MCF51QE128 and its accompanied evaluation board

DEMOQE128 (Figure-1) as hardware platform to test and

demonstrate the application. This demo board is easily

orderable via 3rd party P&E Microcomputer System

(https://www.360docs.net/doc/c614042481.html,/). We use Freescale’s own

software IDE CodeWarrior as the software development

platform. The latest version who supports CF V1 parts is

CW V6.1. You can download a special edition free of charge after logged or registered in Freescale’s web site: https://www.360docs.net/doc/c614042481.html,/

1. Simple theory of Boot-loader

Boot-loader by any means is just a section of specially designed executable code which resides in a carefully allocated memory area in a chosen MCU. It’ll be largely, if not absolutely, transparent to normal user application code flow. However, once activated by

some pre-set conditions, it can take over the full

control of all MCU resources, receive new code data

via any possible communication channels, re-program

the partial or even entire Flash code memory and

finally kick off a brand new application code to run

with the same hardware system.

2. Introduction of V1 memory map

Before designing a boot-loader on a specific MCU,

it’s essential to fully understand its memory map. We

need to put the boot-loader at a specific memory area

where it has least intrusion to normal user application

code. We must well understand how the reset &

interrupt vector scheme works on this particular MCU

so that the boot-loader can manipulate some or all

vectors behind the scene to give the highest efficiency

and flexibility for user applications. Figure-2 shows

the entire memory map on MCF51QE128. In overall it has 128K bytes on-chip Flash memory and 8K DEMOQE128 Figure-1 Memory map on MCF51QE128

Figure-2

bytes of static RAM. The rest are memory mapped peripheral registers which will be very much application centric. For a general purpose boot-loader design, Flash & RAM are two parts which concern us the most.

We must pay special attention to 128K Flash memory as our boot-loader will reside somewhere within this memory space. Out of the 128K Flash space, the first 1K or so bytes are specifically reserved for vector space and some other special purposes. Total 256 vector entries are available although only 103 vectors in V1 core are implemented. All the user code, including boot-loader, must be put in the memory space starting from address 0x0410. Theoretically, boot-loader code section can be put at anywhere in the 128K range except vector and other reserved area. Yet practically it should be positioned either at the beginning of user code memory right after those reserved area, or at the end of entire 128K. This will leave a big chunk of flash memory in linear fashion for user application.

3.Interpret S19 file data format

After the success of code generation in CW IDE, there’ll be a file created with filename extension “S19”. This is the text file containing every byte of code which eventually will be programmed into MCU’s flash memory array. This flash programming is usually accomplished with the help of special programming tools, such as Multilink-BDM or CyclonePro. A boot-loader acts in the very similar way as the standalone programming tools to interpret programming data so it’s necessary to have some basic knowledge on the format of this S19 file.

An S-record file consists of a sequence of specially formatted ASCII character strings. An S-record will be less than or equal to 78 bytes in length. The order of S-records within a file is of no significance and no particular order may be assumed.

The general format of an S-record is following:

+------------------//-------------------//-----------------------+

| type | count | address | data | checksum |

+------------------//-------------------//-----------------------+ ?type: A char[2] field. These characters describe the type of record (S0, S1, S2, S3, S5, S7, S8, or S9).

?count: A char[2] field. These characters when paired and interpreted as a hexadecimal value, display the count of remaining character pairs in the record.

?address: A char[4,6, or 8] field. These characters grouped and interpreted as a hexadecimal value, display the address at which the data field is to be loaded into memory. The length of the field depends on the number of bytes necessary to hold the address. A 2-byte address uses 4 characters, a 3-byte address uses 6 characters, and a 4-byte address uses 8 characters.

?data: A char[0-64] field. These characters when paired and interpreted as hexadecimal values represent the memory loadable data or descriptive information.

?checksum: A char[2] field. These characters when paired and interpreted as a hexadecimal value display the least significant byte of the ones complement of the sum of the byte values represented by the pairs of characters making up the count, the address, and the data fields.

Each record is terminated with a line feed. If any additional or different record terminator(s) or delay characters are needed during transmission to the target system it is the responsibility of the transmitting program to provide them.

S0 Record: The type of record is 'S0' (0x5330). The address field is unused and will be filled with zeros (0x0000). The header information within the data field is divided into the following subfields.

mname is char[20] and is the module name.

ver is char[2] and is the version number.

rev is char[2] and is the revision number.

description is char[0-36] and is a text comment.

Each of the subfields is composed of ASCII bytes whose associated characters, when paired, represent one byte hexadecimal values in the case of the version and revision numbers, or represent the hexadecimal values of the ASCII characters comprising the module name and description.

S1 Record: The type of record field is 'S1' (0x5331). The address field is interpreted as a 2-byte address. The data field is composed of memory loadable data.

S2 Record: The type of record field is 'S2' (0x5332). The address field is interpreted as a 3-byte address. The data field is composed of memory loadable data.

S3 Record: The type of record field is 'S3' (0x5333). The address field is interpreted as a 4-byte address. The data field is composed of memory loadable data.

S5 Record: The type of record field is 'S5' (0x5335). The address field is interpreted as a 2-byte value and contains the count of S1, S2, and S3 records previously transmitted. There is no data field.

S7 Record: The type of record field is 'S7' (0x5337). The address field contains the starting execution address and is interpreted as 4-byte address. There is no data field.

S8 Record: The type of record field is 'S8' (0x5338). The address field contains the starting execution address and is interpreted as 3-byte address. There is no data field.

S9 Record: The type of record field is 'S9' (0x5339). The address field contains the starting execution address and is interpreted as 2-byte address. There is no data field.

Coldfire V1 core is a 32-bit controller which naturally has 32-bit wide address. Therefore possible S-records could be S0, S3, S5, S7. And in practical, S0, S3 & S7 are three most often seen S-records in a S19 file for CF V1.

EXAMPLE:

Shown below is a typical S-record format file on CF V1 code.

S0030000FC

S321000024004E7551FC4E7551FC2F0E2F0CB1C9671C60102C48204E52882849224C1A

S70500002534A1

The S0 record is comprised as follows:

S0S-record type S0, indicating it is a header record.

03Hexadecimal 03 (decimal 3), indicating that three character pairs (or ASCII bytes) follow.

00 00 Four character 2-byte address field, zeroes in this example.

FC The checksum.

The S3 record is comprised as follows:

S3 S-record type S3, indicating it is a data record to be loaded at a 4-byte address.

21Hexadecimal 21 (decimal 33), indicating that thirty-three character pairs, representing a 4 byte address, 28 bytes of binary data, and a 1 byte checksum,

follow.

00 00 24 00 Eight character 4-byte address field; hexadecimal address 0x00002400,

where the data which follows is to be loaded.

4E 75 51 FC 4E 75 51 FC 2F 0E 2F 0C B1 C9 67 1C 60 10 2C 48 20 4E 52 88 28

49 22 4C twenty-eight character pairs representing the actual binary data.

1A The checksum.

The S7 record is comprised as follows:

S7 S-record type S7, indicating it is a termination record.

05 Hexadecimal 05 (decimal 5), indicating that five character pairs follow.

00 00 25 34The address field, hexadecimal 0x00002534 indicating the starting

execution address.

A1The checksum.

For a boot-loader in CF V1 MCU, the most important task is to receive S3-records, interpret each data section and program a string of payload data into flash memory starting from a specified address. S0-record is simply discarded because it contains no meaningful data for programming. S7-record tells the boot-loader it’s the end of S19 file and usually boot-loader will reboot the system with the updated firmware after acknowledge this line.

On PC or other type of data terminal who feeds the S19 data to MCU boot-loader, the data format could be in original ASCII text form as shown in above example. This will be the simplest approach but the download speed will be a bit slow as the S19 text file has lots of redundancy due to the nature of ASCII coding. The boot-loader at MCU side will handle all the data analysis and reformatting. One alternative is to analyze and reformat the S19 text line at PC side and streamline the payload data before sending to MCU boot-loader with user defined protocol. For the implementation in this article, we designed a simple PC software which read every S-record text line, appended with hex code 0x00 as

end-of-line tag, and then send this text string to 51QE128 boot-loader, which will do the rest of the job.

4.Memory segmentation for boot-loader design

Keep in mind that a boot-loader will be activated only when in need. It takes a block of permanent space in flash memory to reside and not a single byte of RAM is required while it’s inactive. When it’s in active mode, there’s no longer any user code running so it’s perfectly okay a boot-loader shares all RAM space with user application at different time. Therefore we only need to allocate proper flash memory space for a boot-loader.

A boot-loader has the capability to reprogram partial or entire flash memory subject to the actual application needs. Both approaches have their own advantages and disadvantages. To reprogram the entire flash, the boot-loader itself must firstly be copied into RAM and run its code from there in rest of the process. The advantage is obvious – it can erase and reprogram the entire code space at your own wishes. The disadvantage is the high risk of reprogramming process abortion because of power-down or any kind of unexpected chip resets. This will leave the code space blank or partially programmed and there’s no way to bring it back except to reprogram the chip with standalone programmer.

A more reliable and safer way is to put the boot-loader code section into a permanent area where it’ll never be erased by boot-loader itself. The goal is to be able to get boot-loader up and running even after all the user application codes are erased, or only partially programmed. To achieve this, boot-loader must be the first part to run after any reset – i.e. the reset vector entry must point to the boot-loader, not user code. Since the boot-loader is fixed in flash memory, the whole vector table MUST also be fixed because a smallest flash page to be erased and reprogrammed is 1024-byte size in V1 core. This again leads to the topic of the redirection of vector entries in user code.

Redirection of vector entry is achieved by setting the original vector table (0x000-0x3FFF) with fixed index entry (address) of another user defined table. The original table will permanently reside in flash memory as same as boot-loader section. The user defined new table will have every entry offset address fixed but the contents in that entry are free to change, usually its content in each entry is a simple “jmp” instruction to jump the code to real vector service routine, which will be either initialization code after reset or any kinds of interrupt service routine. Figure-3 illustrated this kind of approach.

As such, we divided the 128K flash memory into 4 segments: 1K or so bytes of original vector table (with a few bytes of reserved space); 2K bytes of boot-loader code, which can be more or less depends on actual code size requirement; 1K bytes of user defined redirected vector table; the rest are for user applications. The first two segments are fixed in permanent once programmed with standalone programmer, the rest are all user reprogrammable by boot-loader for highest application flexibility. Figure-4 shows the flash memory map under this arrangement.

5. Implementation of boot-loader

Now let’s get into the real design work of an UART based boot-loader on MCF51QE128. As mentioned earlier, we use DEMOQE128 board as the hardware platform so it’s necessary to check with the board schematic for better understanding of any hardware related control or setup in the below demo code.

5.1

Modification of project linker command file (lcf file) When we use CW project wizard to create a new

project, there’ll be a project linker command file

(lcf as its extension filename, see example in

Figure-5) created automatically, which defines the

allocation and usage of all available ROM (flash) &

RAM resources associated with the selected chip.

We must manually alter parts of its contents so as to

get the memory segmentation as per the description

in chapter 4. In this file there is an important text block called MEMORY {} which consists of all the definitions for different memory segments. A

default lcf file for 51QE128 may have memory

definitions look like this:

MEMORY {

code (RX) : ORIGIN = 0x00000410, LENGTH = 0x0001FBF0

Project lcf file Figure - 5

userram (RWX) : ORIGIN = 0x00800000, LENGTH = 0x00002000

}

It simply declares two memory segments, one is for code area (flash ROM) with starting address at 0x00000410 and length of 0x0001FBF0; the other one is for RAM area with starting address at 0x00800000 and length of 0x00002000. Note there’s no need to explicitly declare system vector area as the address range 0x00000000-0x0000040F is already reserved by linker for this purpose.

Now we need to modify this memory declaration to accommodate boot-loader memory segmentation requirement as below.

MEMORY {

userram (RWX) : ORIGIN = 0x00800000, LENGTH = 0x00002000

BootLoad (RX) : ORIGIN = 0x00000410, LENGTH = 0x000007F0

VectorReMap (RX) : ORIGIN = 0x00000C00, LENGTH = 0x00000400

code (RX) : ORIGIN = 0x00001000, LENGTH = 0x0001F000

}

So we divided the flash ROM into 3 segments: 2K bytes (0x00000410-0x00000BFF) specifically for boot-loader; 1K bytes (0x00000C00-0x00000FFF) for vector redirection; and the rest area (0x00001000-0x0001EFFF) are free for user application code.

Next, we need to add something in the middle of another text block called SECTIONS {}. We can leave all the existing contents untouched but add in following lines

# define code sections

.BootLoad : {} > BootLoad

.VectorReMap : {} > VectorReMap

# Code placement for boot-loader section

.text_bootload :

{

BootLoad.c (.text_bootload)

. = ALIGN (0x4);

} >> BootLoad

# Code placement for remapped vector section

.text_vectormap :

{

VectorMap.c (.text_vectormap)

. = ALIGN (0x4);

} >> VectorReMap

The above statement tells the linker where to put boot-loader code segment (declared as “text_bootload” in source file) and vector redirection segment (declared as “text_vectormap” in source file). The key message here is: once we modified this lcf file for boot-loader design, it must be used for user application design in the exactly same form.

5.2Coding of Boot-Loader

Most of the boot-loader coding works are as same as for normal applications, except you must be able to tell the linker that all the codes belong to boot-loader will be eventually put in a special section as stated in lcf file for permanent residence in flash memory. We use “#pragma” to declare a unique code section for this purpose:

//=============================================================================

// Declare a code segment with name "text_bootload"

//=============================================================================

#pragma CODE_SEG __FAR_SEG text_bootload

Note the highlighted section name must match with the reference in lcf file showing in above sect 5.1

5.2.1Create reset vector and its service routine

We shall also tell the complier and linker that boot-loader must be the first part to run after any kinds of reset. We can declare a reset-vector function by doing below:

//=============================================================================

// - Vector 1 - Reset vector

//

// - This portion of code will be executed right after reset.

// - The purpose is to check if it should go to normal code flow or get into

// Boot-loader by checking key-press on PortD pin3 and validity of vector area

//=============================================================================

void interrupt VectorNumber_INITPC FirstHandChk(void)

{

…

}

The keyword “interrupt” tells the complier this is a vector type of function although it’s not a real interrupt for this reset vector. “VectorNumber_INITPC” is pre-defined in project header file MCF51QE128.h as the vector number for MCU reset. By declaring a function in this form, the reset vector in the original vector table will point to this function after code generation.

There are four major parts in this function:

1.Setup key registers A7, A6 & A5 for basic code running environment. A7 is the stack

pointer; A6 is the stack frame register; A5 is used for RAM relative-addressing, if so required;

//setup A7 stack pointer

asm (lea _SP_INIT, a7);

//setup A6 dummy stackframe

asm (movea.l #0, a6);

asm (link a6, #0);

//setup A5

asm (lea _SDA_BASE, a5);

2.Check the hardware key-pressing (associated with eval board hardware). It’ll activate

boot-loader unconditionally if a key-pressing on PortD pin3 is confirmed;

//setup PORTD3 for key-press detection

PTDDD_PTDDD3 = 0; //set PTD3 as input (key)

// check if boot-loader function is activated by pressing PortD pin3

// upon reset

if (!PTDD_PTDD3) { //pin is low - possible key-press detected

for (wTmp=0;wTmp<1024;wTmp++) {} //delay for key debouncing

if (!PTDD_PTDD3) { //double-check to confirm key-press

asm (jmp BootLoader); //Boot-loader activation confirmed, jump to //Boot-loader routine

}

}

3.Or check the validity of user application code contents by simply verifying the

leading 16 bytes of programmed data in new redirected vector table. User can design

a more reliable way which is to calculate the checksum of entire reprogrammable

memory space.

//Boot-loader is not activated by key upon reset,

//Need to further verify if normal code flow exists

//by checking 1st 16 bytes of data in remapped vector area

datPtr = (void*)StartupEntry; //get the starting address by referring to 1st

//entry in redirected vector map

for (bTmp=0;bTmp<16;bTmp++) { //check for consecutive 16 bytes

if (*(byte*)datPtr != 0xff) //break out if any one is not 0xff

break;

((byte*)datPtr)++;

}

if (bTmp==16) { //leading 16 bytes in vector map are all 0xff,

//vector map is invalid

asm (jmp BootLoader); //Jump to Boot-loader routine

}

4.Execute the normal user application code flow if neither special key-pressing is found

upon reset, nor is user code invalid.

//execute normal code follow

asm (jmp StartupEntry); //Jump to normal "startup" routine

5.2.2Boot-loader main working loop

The main boot-loader function also consists of four portions.

//=============================================================================

// Boot-loader main routine

//=============================================================================

void BootLoader(void)

{

…

}

1.Setup key registers A7, A6 & A5 as same as what it does in reset vector routine. This

is because it is possible a boot-loader will be evoked by user code flow after matching with pre-set condition, for example a special command from normal UART communication.

2.Disable all interrupt and do some initialization works. There is no any kind of

interrupt allowed during boot-loader process because the redirected vector table will be erased for new updates. The key initialization works are system clock module and SCI module setup in this example.

DisableInterrupts; //disable all interrupt, no interrupt is allowed

//Do all the initialization works

InitBootLoad();

3.Copy a key portion of flash programming code into RAM buffer for real

programming usage. This is because the code execution running in flash will not be reliable if the flash itself is undergoing erase/programming. Then we do erase for all the user reprogrammable flash space.

//Copy flash-command execution code into RAM

CopyRom2Ram((byte*)FlashCmdExec, 128);

//Erase all pages in reprogrammable area

FlashErase();

4.Execute a dead loop for polling two things – receive S19 text line for new code

download and programming, and check the timer overflow to toggle LEDs as simple user interface signaling.

//Boot-loader main loop

for (;;) {

__RESET_WATCHDOG(); //clear watchdog

ReceiveS19Text(); //polling to process incoming data

TPM1OverflowChk(); //polling to check timer

}

5.2.3Receive S19 line and flash programming

Receiving of S19 text lines are driven by a state-machine showing in below Figure-6. It’ll receive every S19 line and echo back with an ASCII code “.” as acknowledgment. It interprets each S3 line and program the data into designated flash memory. It can automatically reboot the system by deliberately jumping the code to an illegal address once an S7 line is received and acknowledged.

Please refer to project source code for details within function of

void ReceiveS19Text(void){

...

}

5.3Vector redirection

Redirection of original vector table is accomplished by defining a specific code segment where we implement all the interrupt service entry for every possible interrupt source. Yet there is actually no meaningful code in each entry except a simple instruction of code jump to a real service routine implemented in user application. There’s no such need to follow the exact ascending order of natural vector number for this remapping. But once

defined and fixed, the order and size of each service entry MUST NOT be changed in user application. This is because the contents in the original vector table will be filled up with the mapped address when complier and linker generate this boot-loader code, and it’s not alterable again by boot-loader itself once programmed into the flash. For all those unused vector entries we can set a default trap for address redirection so as to keep the code size unchanged even if they’ll be utilized later on. Remember we also need to put this redirected vector table at an address specified in lcf file:

#pragma CODE_SEG __FAR_SEG text_vectormap

Each vector redirection can be written as following in default:

//=============================================================================

// Entry of normal code flow

//=============================================================================

void StartupEntry(void)

{

asm (jmp _startup);

}

void interrupt VectorNumber_Vaccerr ISR_Vaccerr(void)

{

asm (jmp IllegalTrap);

}

void interrupt VectorNumber_Vadderr ISR_Vadderr(void)

{

asm (jmp IllegalTrap);

}

...

void interrupt VectorNumber_VL1swi ISR_VL1swi(void)

{

asm (jmp IllegalTrap);

}

//=============================================================================

// Setup a trap for unexpected interrupt request

//=============================================================================

void IllegalTrap(void)

{

while(1){

;

}

}

Take note the first entry named as “StartupEntry”, which is not an interrupt-type of function. This is because we’ve already set the reset vector in boot-loader segment and this is just a fixed entry to redirect to normal startup code section under standard C programming.

The last piece of vector remap is a simple trap for illegal vector interception, which also acts as a default vector service contents for a boot-loader design.

5.4Dummy main() function in boot-loader design

As we go through standard application development procedure for a special boot-loader design, a dummy main() function is needed to eliminate final linker error. This function is as simple as below:

void BootLoader(void);

#pragma CODE_SEG __FAR_SEG DEFAULT

//=============================================================================

//=============================================================================

void main(void) {

asm (jmp BootLoader); //Jump to Boot-loader routine

}

It simply jumps to the main boot-loader code section, if it ever gets opportunity to run. 5.5Program boot-loader code into flash

Once the boot-loader is coded, complied and linked successful, we can use standalone programmer tools such as MultiLink-BDM or CyclonePro to program the machine code into QE128 flash memory. After removing the programming tools and having a power-up reset, the boot-loader will be running with PTC0 LED flickering at a fast pace on QE128 demo board, indicating it’s in boot-loader mode and ready to receive new firmware via UART port.

6.Coding of user application

Coding of user code is nothing too special, but with some key points in mind:

?Use the same lcf file as for boot-loader project to keep the exact same flash memory segmentation;

?Add module “VectorMap.c” into application project with its file name intact as lcf will filter out “.text_vectormap” section only from this file;

?Within “VectorMap.c”, do not insert or delete the function entry in vector remap segment. Only modify the destination address in “jmp” instruction for redirection of specific interrupt service routine.

The only point worth to elaborate a bit more is the implementation of user specified interrupt service routine. In user code we implement an interrupt service routine simply by assigning a key word “interrupt” in front of function name as below example. There’s no need to assign associated vector number, although it might cause a warning message during compiling, just ignore it.

//=============================================================================

// - User application SCI1 data receive interrupt service routine

// - Must update ISR_Vsci1rx in 'VectorMap.c' for proper re-direction as this:

// asm (jmp App_SCI1Rx_ISR);

//=============================================================================

void interrupt App_SCI1Rx_ISR(void)

{

byte dat;

SCI1S1; //read the status register once to clear RDRF bit

dat = SCI1D; //read the data in SCI buffer, RDRF bit is cleared now

SCI1D = dat; //echo back in test mode

}

In order to get this ISR running as expected, we must modify the code-jump instruction in remapped vector table as below:

//declare function prototype

void App_SCI1Rx_ISR(void);

...

// *** SCI1 RX ISR Utilized

void interrupt VectorNumber_Vsci1rx ISR_Vsci1rx(void)

{

//asm (jmp IllegalTrap); //default entry

asm (jmp App_SCI1Rx_ISR); //user ISR entry

}

Please follow the above example for all user defined ISR redirection – declare user ISR function prototype on top of the code lines firstly and modify the related “jmp” instruction for ISR redirection.

7.PC download software

A simple PC software is developed to test and implement the 51QE128 boot-loader design discussed above. It has three operations: setup the PC UART port to 38400-N-8-1; open an S19 file to download; and download the selected S19 file contents to target board.

8.Project source code and demonstration

Complete reference source code for boot-loader and sample user applications are available. Executable PC side download software is also provided for demo purpose. All the source code are subject to “as is” agreement. Users are free to change the code and take own risk.

To run the demo code, we must firstly program the boot-loader code (BootLoader.S19) into MCU using standalone programmer. The demo board will be running in boot-loader mode if this programming is successful. Connect QE128 demo board and PC with a null-modem RS232 cable, run PC download software and down load a sample application

(DemoApp1.S19) to target board. The new application will start to run automatically after download.

To activate boot-loader again, please hold-down PTD3 key and perform any kind of reset, the board will enter boot-loader and be ready to receive new firmware via UART port. References:

MCF51QE128 reference manual

ColdFireV1 build tools reference