Software bootloader

The following app note is a good starting point: http://focus.ti.com/mcu/docs/mcusupporttechdocsc.tsp?sectionId=96&tabId=1502&abstractName=slaa341

During the Link phase of each project, the Linker reads a file that tells it the starting and ending addresses of each section. You need to copy that file and make two modified versions of it. One for your bootloader project, one for the firmware project.

You also need to tell the Linker to generate the loadable object file with the file format that you can handle, not the default file format that the Debugger wants.

Sorry, I do not have/know CCE and cannot tell you the specifics. But the above principle applies to any development tool.

Thank you for your responses, the hex430 utility was precisely the one, I have been looking for. It allows creation of the .hex file of the specified section and its output perfectly fits to the disassembly window in CCE, so it looks like, it will be possible to upgrade firmware correctly.

Thank you, best regards Lookash

Hi,

unfortuneately, this app-note is in assembly language :[:#]--> are there any plans to port it to C-language (even in case the memory requirement will increase)?

The monitor is able to flash INFOA and INFOB segment only; how to modifiy this to only allow flashing of INFOB to INFOD and not INFOA (because of calibration data).

Do I realy need a 32,768Hz crystal when using the monitor as is or is this only an example (because using a watch crystal will not result in outstanding performance even with a 16bit CPU).

Thanks for answering, regards
G**buster

G**kbuster said:

unfortuneately, this app-note is in assembly language :--> are there any plans to port it to C-language (even in case the memory requirement will increase)?

I doubt that this report will have a C-language update in the future.

Hi, LukasRiedel, I am doing the same project. In your project, you have a bootloader code part, and you also have a application code part. Did you create two seperate projects and get two .out file then link to different memory locations? or did you just created one project, and then use hex430 to seperate the .out file according to different sections? I wish to know your design flow for bootloader. thanks

Hi, I have only one project, which consists of several files and sections. There are two main sections: bootloader and main defined in .lnk file of the project such as:

MEMORY

{

    BOOTLOADER : origin = 0xE200, length = 0x0A00

    FLASH : origin = 0xEC00, length = 0x13C0

}

SECTIONS

{

    .boot : {} > BOOTLOADER /* SOFTWARE BOOTLOADER */

    .text : {} > FLASH /* CODE */

}

The reset vector leads to the start of the .boot section. There is solved, whether the programme is loaded correctly or it is required to download a new one (or few remaining parts). The bootloader can handle basic functionality of CC1101 chip, can erase and program flash memory and that is all. Just the minimum functionality. When the code is correctly placed in the .main section, the programme jumps at its begining.

The hex430 utility enables creating binary for just specified sections, so I use it in this way:

Command file config.txt:

"project.out"
-i
-o project.hex
-memwidth 16
-romwidth 16
-order LS
SECTIONS
{ .text
}

And then I just call hex430 config.txt in the command line.

Hi,

ever thought about sharing the code with other E2E community members? Why should people re-invent the wheel again and again ;*) ?

Rgds
G**kbuster

Hi, LukasRiedel

Fortunately I had someone done this before me. Thank you so much.

I had basically understood what you are doing. but, I wish to know how did you separate the code into two sections (the boot section and main section, which utility does the separation work)?

Could you take a look at whether my design flow is executable or not?

1. create a new c function "boot" in main project.

2. use "assembler utility" allocate different C functions into different sections in object file? (am I correct?)

3. use "linker utility" link different sections into different memory locations.

4.  use hex430 utility creating binary image for main sections

5. set reset vector leads to the start of the .boot section.

...

To be more specific, How did you create the .boot section? What all I got is just a .text section which contains everything, I don't know how to seperate them into two sections.

Thanks thanks so much.

Hi, I am writing all in assembler, so I will not be able to tell you, how you can do it with use of C language. But it can give you some hints.

file attached to the project with linking information lnk_msp430f2132.cmd, contains (among others) these parts:

MEMORY

{

    TABULKA : origin = 0xE000, length = 0x0200 // 512B

    BOOTLOADER : origin = 0xE200, length = 0x0A00 // 2560B

    FLASH : origin = 0xEC00, length = 0x13C0 // az FFC0 -> 5056B

}

SECTIONS

{

.tabulka : {} > TABULKA

.boot : {} > BOOTLOADER /* SOFTWARE BOOTLOADER */

.text : {} > FLASH /* CODE */

}

That means, that I say the linker, that my whole flash memory will consists of three sections: "TABULKA" (begins at 0xE200 with length 512B), "BOOTLOADER" and "FLASH". That said MEMORY directive. The SECTIONS then specify, that all code, which is after ".boot" will be placed in memory from 0xE200 and can contain maximally 2560B of code.

That was definition of separating the whole unified flash memory into several parts.

Now I have in my project several files, for example "bootloader.asm" and "main.asm"

"bootloader.asm" can look like:

    .cdecls C,LIST, "msp430x21x2.h"

    .sect ".boot"

booting

    mov.w #0x3FE, SP   ; stackpointer initialization

    mov.w #WDTPW+WDTHOLD, &WDTCTL ; stop WDT

    br #0xEC00        ; go to main

;*************** INTERRUPT VECTORS ***********

    .sect ".reset" ; MSP430 RESET Vector

    .short booting

    .end

And the "main.asm"

    .text

main

    jmp $

    .end

After reset, programme goes to the .boot section, solves its tasks there and then gives the control to the address 0xEC00 -> what is the begining of .text section. When I need reprogramme the .text part, I prepare its code, use the hex430 utility, as I wrote several posts before and get the binary of .text section. The flow is given to the bootloader, binary code is written to the flash memory from address 0xEC00 and when all is done, the programme branches again at 0xEC00 and new programme is performed.

I am developing the application for MSP430F2272 in CCE and one feature of the device should be the ability to upgrade its firmware during its life. The device consists of the MSP and radio chip, so the new firmware will come to the processor via radio packets. A newer version firmware is stored in external memory first; when the device starts, the bootloader program will check the application image file that stored in external flash memory, if it is newer than current firmware (onchip memory) , just load the new version firmware to onchip "program space". Now, I am having a complete application project which is written in C.

----------------------------------------

So I intend to organize program like this:

Few segments of flash memory dedicated to the bootloader software - unchangeable, which just doing a simple action that copy the application image from external flash memory and then replace with the current firmware .

Generally, I learn some basic steps to do that, but not sure whether am I on the right track.

=========================================

1. DSP memory configuration for flash booting

         Create the necessary memory segments (I am having trouble at the first step about segments creation)

         Configure the memory sections with the proper load/run address


2. Write the bootloader (Must the bootload part be done in assembly language? C ok? Is there any document to guild me ? Do I need secondary bootloader?)

           − Create the user linker command file
           − Create the copy table by either (confusing)


3. Convert COFF format (.out) to hex file for flash programmer

          - Create the hex.cmd file with the proper options

          − Run hex6x to create the .hex file (the newer version of firmware)

          − Program the flash using the Flash Burn Utility
========================================================

 Is there any good starting point?

could anyone gives me some advices, or gives me some reading link!!!

Thanks a lot.[:)]

Thank you so much for your responses. That is making more sence now.I have another question,

How did you deal with other sections when you create the image? such as: .const, .cinit, .bss ..., did you put all of them in one .hex packet? or just leave them don't care and only update .text?

As I understand it, the sections .const, .cinit, .bss serves only for more user-friendly approach, while programming MSP. To be more precise: when you create the variable in .bss section and work with it in your code, all what is done in .asm -> .out proccess is replacing its name by physical address in RAM memory. And it would be similar with other sections. So if you create .out file from the whole project, you will get an output, which is just flash programme with the correct access into the RAM via absolute addresses. By correct access I mean, that one variable is at the one address, there won't be any unwanted rewrites (because you had it correctly allocated with .bss section in your source code) and so on...

So it is enough to genereate .hex file just from the .text section.

Edit: As I see, the .cinit and .const sections are put in the flash, so if you change .text section and have .text, .cinit. and .const sections in the same SECTION of the flash memory, you will have to update all of them, because they can move in the flash memory according to the size of the .text section. If you have them in the separate dedicated part of the flash memory, their update will not be necessary.

I am working for MSP430f2272

When I am using hex430, there is an option to specify hex format.

-a Select ASCII-Hex
-i Select Intel Section
-m Select Motorola-S Section
-t Select TI-Tagged Section
--ti_txt Select TI-Txt Section
-x Select Tektronix (default)

in order to make the image excecutable in FLASH, which one should I use ?

Anyone you want. They differ just in the syntax, how interpret their contents. For example if you use the config.txt command file, which I mentioned above with the option -a, you will get something like this:


$Aec00,
C0 F2 00 40 00 19 40 B2 FF 7E 01 70 40 B2 01 22 01 60 D0 72 00 D0 D0 F2
00 40 00 19 40 B2 C0 00 01 70 40 B2 01 22 01 60 D0 72 00 D0 3F E9


where after $ sign, there is an address where are the bytes - all data after address begin. If you have discontinuities in your code, there will be other address tags, otherwise the data will continue until the end of file.

Mode -i will produce standard .hex file with this syntax:

:20EC0000C0F20040001940B2FF7E017040B201220160D07200D0D0F20040001940B2C000B4
:0EEC2000017040B201220160D07200D03FE9C5
:00000001FF

where after colon there are 4 control bytes followed by data and the checksum in the end. In my example

:20 on the first line or :0E at the second line means, there are 32, resp. 15 data bytes on the line

EC00, EC20 are the starting addresses in memory, where the data bytes should be placed

00 after address means, that the data are after it. At the last line this attribute is set to 01, what means, that the end of file occured.

The last byte B4, C5, FF is the checksum of the previous contents of the line.

I use the -i option, but you can use whatever you want. Just need to know, what to do with all those bytes. Maybe the Disassembly window while debugging in CCE can also give you few hints, because you can see there, how any instruction of your code is converted into raw data (same data which will occure in your .hex file), so the orientation and verification of your output can be a bit easier.

But, can I just directly download .hex (as a file) to flash? and excecute it? It seems doesn't work for me. Did you make some further format conversion?

Oh, I see, I have to convert my .hex file to binary file before downloading, there is a software called hex2bin, ah, yes, my bootloader is working now. Happy.

Thanks for all the help from you.

Hi, LukasRiedel

I am closing finish, should be my last question, how did you change the reset vector?

after reset, the default location to start the program is 0x8000;

how can my make the starting reading address to be 0x9000?

This was written few days ago, it could help. But once again, it is in the assembler, but I believe you will be able to find an alternative for C

"bootloader.asm" can look like:

 

    .cdecls C,LIST, "msp430x21x2.h"

    .sect ".boot"

booting

    mov.w #0x3FE, SP   ; stackpointer initialization

    mov.w #WDTPW+WDTHOLD, &WDTCTL ; stop WDT

    br #0xEC00        ; go to main

 

;*************** INTERRUPT VECTORS ***********

    .sect ".reset" ; MSP430 RESET Vector

    .short booting

    .end

And the "main.asm"

    .text

main

    jmp $

    .end

All solves the "Interrupt Vectors" part. In .cmd file of your project, there is the definition, on which address the reset vector can be found. By the instruction ".short booting" I said, that when the reset occurs and the programme gets to the reset vector, it should go to the label "booting" (and the start of the booting was defined in .cmd file again for example to the address 0x9000).

Hello,

Please anyone can provide sample code for bsl which replaces user code with new one. I am using MSP430F5436A...

Regards,

Sunil