BSL BOOTLOADER MSP430F5418A

Gerard van Leeuwen

Other Parts Discussed in Thread: MSP-FET, MSP430F5438A, MSP430F5418A, MSP430F6779

I have downloaded the SLAA450 zip file that contains the bootloader example for the MSP430F5438A. I setup the project settings in such a way that the code is able to download in a MSP430F541A. I am using a board that runs ok and is able to debug with the MSP-FET. After some struggle to find the correct compiler and settings to be able to reporgram the BSL area I succeeded in porgramming the standard BSL example code.

I changed the main() in such a way that an outputpin is toggled with a fixed delay. On this pin a LED is connected so that I can see that the code resides in the flash and when debugging the project the uP starts up correctly. At that moment the debugger stops in main() on the first instruction. When I press on the resume button (F8) the code runs fine. the LED toggles correctly. So far no porblems ...

But when I power up the board without the debugger, the uP does not seem to start up. The LED is not toggled. So probably the debugger performs a start to the first location of the software ..

Reading the pdf (slaa450c) I understand that the uP does a "Device Startup Sequence" and checks a number of flags in the segment BSLSIG

BSLSIG : origin = 0x17F0, length = 0x000C

When I look into the assembly file 'BSL430_Low_Level_Init.asm' that comes with the BSL bootloader, I noticed that at this segment the correct values are written to start the BSL:

.sect ".BSLSIG";

.word 0xFFFF ; 0x17F0 = 0xFFFF

BslProtectVecLoc .word BSL_Protect ; 0x17F2 = adress of function

PBSLSigLoc .word 03CA5h ; 0x17F4 = 1st BSL signature

SBSLSigLoc .word 0C35Ah ; 0x17F6 = 2nd BSL signature

.word 0xFFFF ; 0x17F8 = 0xFFFF

BslEntryLoc .word BSL_Entry_JMP ; 0x17FA = start address of the BSL ...

So I am a little stuck now... How can I power up my board to first start the BSL...?? I hope that somebody has had this problem or can help me with this...

over 10 years ago

0 Gerard van Leeuwen over 10 years ago

Intellectual 325 points

I also produced a .txt file of this small BSL project:

@1000

05 3C 80 00 14 10 FF 3F FF 3F FF 3F 30 40 42 10

00 08 08 04 3D 90 AD DE 04 20 3E 90 EF BE 01 20

03 3C 0C 43 0D 43 10 01 3C 41 3D 41 10 01 0C 43

B2 D0 03 80 82 01 B2 B0 10 00 80 01 01 24 2C D3

10 01 31 40 00 5C B0 13 42 11 0C 43 B0 13 5A 10

B0 13 4E 11 32 D0 10 00 FD 3F B2 40 80 5A 5C 01

C2 43 02 02 F2 D0 73 00 04 02 C2 43 03 02 5F 42

05 02 F2 43 05 02 C2 43 22 02 F2 D0 41 00 24 02

C2 43 23 02 F2 D0 E6 00 25 02 C2 43 42 02 F2 D0

3F 00 44 02 C2 43 43 02 F2 D0 FC 00 45 02 C2 43

62 02 5F 42 64 02 F2 43 64 02 C2 43 63 02 5F 42

65 02 F2 43 65 02 82 43 22 03 B2 D0 FF 00 24 03

F2 D0 40 00 02 02 F2 D0 20 00 02 02 F2 F0 EF 00

02 02 B2 40 33 02 68 01 82 43 60 01 B2 40 40 00

62 01 82 43 6A 01 B2 40 3C 20 64 01 0E 41 3E 80

00 1C 3F 40 FE 1B 0F 5E 8F 43 00 00 2F 83 2E 83

FB 23 82 43 0E 1D F2 F0 EF 00 02 02 B0 13 1E 11

F2 D0 10 00 02 02 B0 13 1E 11 F5 3F 03 43 21 83

3F 40 E8 03 B1 40 64 00 00 00 91 83 00 00 02 3C

91 83 00 00 B1 93 00 00 FB 23 1F 83 F3 23 21 53

10 01 B2 40 80 5A 5C 01 32 C2 03 43 10 01 03 43

FF 3F

@17f0

FF FF 2E 10 A5 3C 5A C3 FF FF 00 10 FF FF FF FF

@ffd2

54 10 54 10

@ffda

54 10 54 10 54 10 54 10 54 10 54 10

@ffea

54 10 54 10 54 10 54 10 54 10 54 10 54 10 54 10

54 10 54 10 42 10

0 Katie Pier over 10 years ago in reply to Gerard van Leeuwen

TI__Guru 73236 points

Hi Gerard,

With the default BSL, an entry sequence has to be provided on RST and TEST to cause it to enter BSL. See www.ti.com/lit/pdf/slau319 which talks about how to communicate with the BSL from a host.

Now there is a small piece of the BSL that runs at startup to check for this sequence - in BSL430_Low_Level_Init.s43 that you mentioned, the BSL Protect function is what runs. See www.ti.com/lit/pdf/slaa450 Figure 1 to see the device startup sequence. At startup, the device checks the BSL signatures, and if they are set correctly, then it will set PC to 0x17F2, the BSL Protect function. You can see that in this function, there is the line

"bit #SYSBSLIND,&SYSCTL ;check for BSL start request"

This line is checking the SYSBSLIND bit in the SYSCTL register. In the 5xx user's guide www.ti.com/lit/pdf/slau208 you can see in section 1.9 Booststrap Loader (BSL) that SYSBSLIND will only be set if the correct entry sequence was detected on RST and TEST.

So right now, when you are trying to run your code stand-alone, you are not having the BSL enter because the entry sequence has not been applied. You can either

provide the entry sequence on RST and TEST (you can use something like the app note www.ti.com/lit/pdf/slaa535 )
Load application code into main memory that does the BSL software entry - this is done by jumping to 0x1000 and there are a lot of other threads about this, or see section 3.8.1 Starting the BSL from an External Application of www.ti.com/lit/pdf/slau319
change the BSL_Protect function in BSL430_Low_Level_init to enter BSL based on some other criteria (maybe have it enter if some value is not present in a particular flash location, or if a particular GPIO is held high, or whatever you need for your application use-case).

Hope this helps,

Katie

0 Gerard van Leeuwen over 10 years ago in reply to Katie Pier

Intellectual 325 points

*** SORRY for the long answer, I hope that you can find the time to read it all and answer my additional questions ***

Yes this helps! My lack of knowledge of the JTAG-interface / assembly language is the cause that I did not understand what happen at this line:

bit #SYSBSLIND,&SYSCTL ;check for BSL start request

offcourse I understand that this does a bit-test, but I did not check what was inside the register SYSCTL

for now I commented these 2 lines in the source code:

;;; bit #SYSBSLIND,&SYSCTL ;check for BSL start request

;;; jz BCC2BSL

and now the device start the 'main' of the bootloader software. Also when I repeat the resetsequence (power down and up) the bootloader now starts everytime... so that is OK

====

For this project we require to transmit over RS485. The bootloader checks some dedicated bytes in RAM and when the signature tells the bootloader to start, it will auto-erase the application area. after that it will readout the address-settings from a dipswitch and wait for a datapacket (kind of modbus protocol). I hope that I can squeeze everything in 2k words :)

In the API I noticed that there are a lot of commands to read, erase and write the flash of the application area. I noticed that the flashrom for the 5418A is a little strange:

FLASH : origin = 0x5C00, length = 0xA380 >> end address at 0xFF7F << ???

FLASH2 : origin = 0x10000,length = 0x15C00

I see a gab of 0x80 bytes that is used for the interrupt vectors and reset-vector. That is understandable. Probably the linker will take care of that so that is fine...

My question is raised when I created a txt-file of the BSL software. I noticed that the BSL also produces code in the segment 0xFF80 - 0xFFFF. I notice some interrupt functions in that area and also the resetvector at FFFE (0x1042). It seems that the interrupts are all jumping to 0x1054

@ffd2

54 10 54 10

@ffda

54 10 54 10 54 10 54 10 54 10 54 10

@ffea

54 10 54 10 54 10

54 10 54 10 54 10 54 10 54 10 54 10 54 10 42 10 << 0xFFFF

Checking the map-file I noticed an asm function at 0x1054 called TI_ISR_TRAP so probably no interrrupts are required by the BSL bootloader. But offcourse, the resetvector will be overwritten once you save an application. Or??? does the 'device startup sequence' first starts nebore the uP start to the reset-vector ???

What happens when a application is stored and overwrites the interrupt vectors and resetvector at this location? Does the uP still starts the BSL-software??

===

I tried to find out what would happen by creating a simple APP that would toggle a (different) LED once it starts.. Since my bootloader is not operating yet, I first programmed the BSL bootloader (only patched , followed by the demo-APP. When I now power-up the board sometimes the bootloader starts and sometimes the APP. Does that make sense? How is this possible???

For me, it is fine that my BSL starts first. I will check a dedicated address where I will place my start-address. And the resetvector, I will not overwrite this one by the BSL if that does the trick... But how does your BSL do this?

0 Gerard van Leeuwen over 10 years ago in reply to Gerard van Leeuwen

Intellectual 325 points

OK, I guess I found the answer in the document "MSP430 Programming Via the Bootstrap Loader" in chapter 1.3

1.3 Standard RESET and BSL Entry Sequence

1.3.1 MSP430 Devices With Shared JTAG Pins

Applying an appropriate entry sequence on the RST/NMI and TEST pins forces the MSP430 to start program execution at the BSL RESET vector instead of at the RESET vector located at address FFFEh.

So the only thing I can do is to patch the address FFFE. Once my bootloader sees this address to be reprogrammed, place this at an other location, forcing the BSL to be started at any time.... Or is there another backdoor to start the BSL without manipulating the TEST-pin? Offcourse I could jump to the BSL in my application and setup my startup software at a dedicated fixed address ...

last question: Why does a BSL start when no app is programmed inside the flash?

0 Katie Pier over 10 years ago in reply to Gerard van Leeuwen

TI__Guru 73236 points

Hi Gerard,

For your question about the interrupt vectors being generated when you build the BSL project:

the interrupt vectors are always generated when you build a project, and if there are no interrupt service routines in your application by default the IDE is having them all point to a TRAP ISR - this feature is to help keep the program from jumping off somewhere unknown if you accidentally enabled an interrupt without creating an ISR for it. The BSL does not (and cannot) use any interrupts (they'd cause your execution to jump out of the BSL area and that would cause the BSL to exit) so they're all pointing to the trap ISR.

The only value different as you can see is 0xFFFE which is the reset vector. This is pointing to a location for your BSL starting. In normal usage, you don't normally have the BSL start at reset - rather you have the reset vector pointing to the address for starting your main application code, and the BSL is just started via the entry sequence (or you may set some custom means). So basically, when you make your BSL code, don't use interrupts, and when you generate your code image, you can get rid of these interrupt vector addresses and just have your code that's in the BSL area at 0x1000. You'll see that in the released BSL images that we provide in the SLAA450 download, the code space used is only at 0x1000 - the compiler just always generates values for the interrupt vectors, and you can get rid of these.

So you may ask, how is BSL_Protect ever called and used to determine whether or not to enter the BSL, if the reset vector is not pointing there? This is because BSL_Protect is called before the reset vector is used to jump to the start of code. As part of the device booting, it every time after a BOR checks the BSLSig addresses to see if a BSL present, and then calls the BSL_Protect function - the fixed address BSLProtectVecLoc in the BSLSIG area contains data for the address of the BSL_Protect function.

So basically every time at startup the boot code in ROM of the device is checking these fixed addresses and jumping to the address in the BSLProtectVecLoc vector which jumps to the BSL_Protect function. BSL_Protect returns with BIT1 in R12 either set 1 or cleared 0 to indicate if BSL should be started or not (see www.ti.com/lit/pdf/slaa450 section 1.2.1.2). If the BSL_Protect function decides to jump to BSL, BIT 1 in R12 is set to 1 (see line 235 of BSL430_Low_Level_Init.s43: " BIS.W #BSL_REQ_APP_CALL, RET_low" and note that RET_low is really R12 if you check the #define at the top of the file). If this happens, then when the function returns the PC is loaded with the BSL start address and the BSL is executed (instead of ever jumping to the reset vector at 0xFFFE). If the BSL_Protect function instead returns and indicates not to enter BSL (BIT1 in R12 = 0), then the startup code continues and PC is loaded with the address located in the reset vector to begin main application code execution instead.

For your other questions, I'll ask: what is your desired behavior for your custom BSL to enter? Do you want it to always enter? Do you want it to enter based on a certain address being at some location in flash, or a pin state or something?

Basically, you're going to want to take your criteria and put it in assembly code in the BSL_Protect function instead of this SYSBSLIND check, and have BIT1 of RET_low (R12) be indicating if you want the BSL to enter or if you just want to run your main code instead. So this is where you'll put any checking - checking a pin, checking an address, etc - or if you always want BSL to be called you can just have it always have it return with BIT1 set.

Gerard van Leeuwen said:
last question: Why does a BSL start when no app is programmed inside the flash?

If you are asking why you can load your BSL program, and have nothing in main, and it starts the BSL? This is because you had the reset vector loaded with the BSL start, so it is going to end up running no matter what BSL_Protect returned. When you write in your main program, the reset vector will get written with the address for your main program, and this won't happen. In that case it will only be entered based on how you have the BSL_Protect returning the R12 value, based on whatever criteria you set in that function. Alternately if you had deleted the interrupt vector locations from your TI-txt file, you could load that file and still have the vectors be blank - in this case also the BSL will not enter with an empty main flash b/c the reset vector is not set to point at BSL (unless you had modified your BSL_Protect function to start BSL on a blank part/ blank reset vector).

I'm not sure if you were really asking this, but as a note - the USB BSL on USB parts (like F55xx) has a condition in BSL_Protect to enter BSL if the reset vector is empty (you can see this in the USB BSL example code from SLAA450). This is a condition I've seen others do as well, to automatically put the part in a BSL mode if the part is blank or some failed load has occurred - typically when you do a loading of new code via BSL, you'd have it clear the reset vector first, and write the reset vector very last, so that if anything interrupts the load, your BSL will know when the part resets that good code is not present and it should re-run to re-load good code.

Regards,

Katie

0 Jens-Michael Gross over 10 years ago in reply to Gerard van Leeuwen

Guru 227245 points

Well, the entry sequence is tested by software. It is the default one and supported by hardware. However, the BSL can perform any other test, like checking a port pin, whatever you want. In your own BSL, you don't have to check SYSBSLIND in the entry check. You can even always enter the BSL and wait for a communication timeout before proceeding to launch the application (if 0xFFFE contains a valid reset vector).
SYSBSLIND just has the advantage that it doesn't need any port pins and that it can be triggered before the CPU starts, so it doesn't take time if the entry sequence is not applied.

0 Gerard van Leeuwen over 10 years ago in reply to Katie Pier

Intellectual 325 points

Thank you Katie for your answer. Because we are in different time zones, it gave me the time to do some further testings.

1) We want to be able to have the BSL code to run at every start, so I set the bits to startup the BSL always. I have to do this because it may happen that no application is valid. Since the applications are programmed via RS485 I only have a serial startup sequence (no DTR/CTS or other lines that I can use).

2) Since the resetvector is used by the BSL and application, I setup the resetvector to the start of the application (0x5C00) followed by a signature of the application (version, size & CRC for the application area). The BSL will check these before getting the address of the resetvector at 0x5C00. When all is OK, the BSL will start the application.

This was the only solution for me to get it working.... For you maybe a strange solution but it looks like that this is working fine sofar...

0 Gerard van Leeuwen over 10 years ago in reply to Jens-Michael Gross

Intellectual 325 points

Well I found out that when the resetvector is set to the application, the uP sometimes starts up to the BSL and sometimes to the APP. So my solution is to set the resetvector to the BSL . The resetvector for the APP I setup to 0x5C00 and the BSL checks that location to start the APP when it is validated

0 Gerard van Leeuwen over 10 years ago in reply to Gerard van Leeuwen

Intellectual 325 points

My Bootloader is working fine, but I want to add some features that requires some extra flash. I wanted to use a small area at location 0x1980 but when I add this to the flashmap, my code does not work when my linker places some functions in this area. Is it not allowed to use this section? See also attached .cmd file

0 Gerard van Leeuwen over 10 years ago in reply to Gerard van Leeuwen

Intellectual 325 points

/* ============================================================================ */

/* */

/* Redistribution and use in source and binary forms, with or without */

/* modification, are permitted provided that the following conditions */

/* are met: */

/* */

/* * Redistributions of source code must retain the above copyright */

/* notice, this list of conditions and the following disclaimer. */

/* */

/* * Redistributions in binary form must reproduce the above copyright */

/* notice, this list of conditions and the following disclaimer in the */

/* documentation and/or other materials provided with the distribution. */

/* */

/* * Neither the name of Texas Instruments Incorporated nor the names of */

/* its contributors may be used to endorse or promote products derived */

/* from this software without specific prior written permission. */

/* */

/* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" */

/* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, */

/* THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR */

/* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR */

/* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, */

/* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, */

/* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; */

/* OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, */

/* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR */

/* OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, */

/* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */

/* ============================================================================ */

/******************************************************************************/

/* lnk_msp430f5418a.cmd - LINKER COMMAND FILE FOR LINKING MSP430F5418A PROGRAMS */

/* */

/* Usage: lnk430 <obj files...> -o <out file> -m <map file> lnk.cmd */

/* cl430 <src files...> -z -o <out file> -m <map file> lnk.cmd */

/* */

/*----------------------------------------------------------------------------*/

/* These linker options are for command line linking only. For IDE linking, */

/* you should set your linker options in Project Properties */

/* -c LINK USING C CONVENTIONS */

/* -stack 0x0100 SOFTWARE STACK SIZE */

/* -heap 0x0100 HEAP AREA SIZE */

/* */

/*----------------------------------------------------------------------------*/

/****************************************************************************/

/* SPECIFY THE SYSTEM MEMORY MAP */

/****************************************************************************/

MEMORY

{

SFR : origin = 0x0000, length = 0x0010

PERIPHERALS_8BIT : origin = 0x0010, length = 0x00F0

PERIPHERALS_16BIT : origin = 0x0100, length = 0x0100

RAM : origin = 0x1C00, length = 0x3FF0

BL_RAM : origin = 0x5BF0, length = 0x0010

/* RAM : origin = 0x1C00, length = 0x4000 */

FLASH_INFO : origin = 0x1980, length = 0x0200

INFOA : origin = 0x1980, length = 0x0080

INFOB : origin = 0x1900, length = 0x0080

INFOC : origin = 0x1880, length = 0x0080

INFOD : origin = 0x1800, length = 0x0080

ZAREA : origin = 0x1000, length = 0x0010

BSL430_VERSION_VENDOR : origin = 0x1010, length = 0x0001

BSL430_VERSION_CI : origin = 0x1011, length = 0x0001

BSL430_VERSION_API : origin = 0x1012, length = 0x0001

BSL430_VERSION_PI : origin = 0x1013, length = 0x0001

ZAREA_CODE : origin = 0x1014, length = 0x002E

// RESET : origin = 0x1042, length = 0x0002

BOOTLOADER_INFO : origin = 0x1044, length = 0x0008

FLASH : origin = 0x104C, length = 0x07A4

// FLASH : origin = 0x1044, length = 0x07AC

// FLASH : origin = 0x1042, length = 0x07AE

BSLSIG : origin = 0x17F0, length = 0x000C

JTAGLOCK_KEY : origin = 0x17FC, length = 0x0004

// FLASH2 : origin = 0x10000,length = 0x15C00

INT00 : origin = 0xFF80, length = 0x0002

INT01 : origin = 0xFF82, length = 0x0002

INT02 : origin = 0xFF84, length = 0x0002

INT03 : origin = 0xFF86, length = 0x0002

INT04 : origin = 0xFF88, length = 0x0002

INT05 : origin = 0xFF8A, length = 0x0002

INT06 : origin = 0xFF8C, length = 0x0002

INT07 : origin = 0xFF8E, length = 0x0002

INT08 : origin = 0xFF90, length = 0x0002

INT09 : origin = 0xFF92, length = 0x0002

INT10 : origin = 0xFF94, length = 0x0002

INT11 : origin = 0xFF96, length = 0x0002

INT12 : origin = 0xFF98, length = 0x0002

INT13 : origin = 0xFF9A, length = 0x0002

INT14 : origin = 0xFF9C, length = 0x0002

INT15 : origin = 0xFF9E, length = 0x0002

INT16 : origin = 0xFFA0, length = 0x0002

INT17 : origin = 0xFFA2, length = 0x0002

INT18 : origin = 0xFFA4, length = 0x0002

INT19 : origin = 0xFFA6, length = 0x0002

INT20 : origin = 0xFFA8, length = 0x0002

INT21 : origin = 0xFFAA, length = 0x0002

INT22 : origin = 0xFFAC, length = 0x0002

INT23 : origin = 0xFFAE, length = 0x0002

INT24 : origin = 0xFFB0, length = 0x0002

INT25 : origin = 0xFFB2, length = 0x0002

INT26 : origin = 0xFFB4, length = 0x0002

INT27 : origin = 0xFFB6, length = 0x0002

INT28 : origin = 0xFFB8, length = 0x0002

INT29 : origin = 0xFFBA, length = 0x0002

INT30 : origin = 0xFFBC, length = 0x0002

INT31 : origin = 0xFFBE, length = 0x0002

INT32 : origin = 0xFFC0, length = 0x0002

INT33 : origin = 0xFFC2, length = 0x0002

INT34 : origin = 0xFFC4, length = 0x0002

INT35 : origin = 0xFFC6, length = 0x0002

INT36 : origin = 0xFFC8, length = 0x0002

INT37 : origin = 0xFFCA, length = 0x0002

INT38 : origin = 0xFFCC, length = 0x0002

INT39 : origin = 0xFFCE, length = 0x0002

INT40 : origin = 0xFFD0, length = 0x0002

INT41 : origin = 0xFFD2, length = 0x0002

INT42 : origin = 0xFFD4, length = 0x0002

INT43 : origin = 0xFFD6, length = 0x0002

INT44 : origin = 0xFFD8, length = 0x0002

INT45 : origin = 0xFFDA, length = 0x0002

INT46 : origin = 0xFFDC, length = 0x0002

INT47 : origin = 0xFFDE, length = 0x0002

INT48 : origin = 0xFFE0, length = 0x0002

INT49 : origin = 0xFFE2, length = 0x0002

INT50 : origin = 0xFFE4, length = 0x0002

INT51 : origin = 0xFFE6, length = 0x0002

INT52 : origin = 0xFFE8, length = 0x0002

INT53 : origin = 0xFFEA, length = 0x0002

INT54 : origin = 0xFFEC, length = 0x0002

INT55 : origin = 0xFFEE, length = 0x0002

INT56 : origin = 0xFFF0, length = 0x0002

INT57 : origin = 0xFFF2, length = 0x0002

INT58 : origin = 0xFFF4, length = 0x0002

INT59 : origin = 0xFFF6, length = 0x0002

INT60 : origin = 0xFFF8, length = 0x0002

INT61 : origin = 0xFFFA, length = 0x0002

INT62 : origin = 0xFFFC, length = 0x0002

// RESET : origin = 0x1042, length = 0x0002

RESET : origin = 0xFFFE, length = 0x0002

}

/****************************************************************************/

/* SPECIFY THE SECTIONS ALLOCATION INTO MEMORY */

/****************************************************************************/

SECTIONS

{

.bss : {} > RAM /* GLOBAL & STATIC VARS */

.data : {} > RAM /* GLOBAL & STATIC VARS */

.sysmem : {} > RAM /* DYNAMIC MEMORY ALLOCATION AREA */

.stack : {} > RAM (HIGH) /* SOFTWARE SYSTEM STACK */

.ZAREA : {} > ZAREA

.BSL430_VERSION_VENDOR : {} > BSL430_VERSION_VENDOR

.BSL430_VERSION_CI : {} > BSL430_VERSION_CI

.BSL430_VERSION_API : {} > BSL430_VERSION_API

.BSL430_VERSION_PI : {} > BSL430_VERSION_PI

.BOOTLOADER_INFO : {} > BOOTLOADER_INFO

.ZAREA_CODE : {} > ZAREA_CODE

.BSLSIG : {} > BSLSIG

.JTAGLOCK_KEY : {} > JTAGLOCK_KEY

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

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

.text:_isr : {} > FLASH /* ISR CODE SPACE */

#ifdef __LARGE_DATA_MODEL__

.cinit : {} > FLASH | FLASH_INFO /* INITIALIZATION TABLES */

.const : {} > FLASH | FLASH_INFO /* CONSTANT DATA */

#else

.cinit : {} > FLASH /* INITIALIZATION TABLES */

.const : {} > FLASH /* CONSTANT DATA */

#endif

.cio : {} > RAM /* C I/O BUFFER */

.pinit : {} > FLASH /* C++ CONSTRUCTOR TABLES */

.init_array : {} > FLASH /* C++ CONSTRUCTOR TABLES */

.mspabi.exidx : {} > FLASH /* C++ CONSTRUCTOR TABLES */

.mspabi.extab : {} > FLASH /* C++ CONSTRUCTOR TABLES */

.infoA : {} > INFOA // MSP430 INFO FLASH MEMORY SEGMENTS

.infoB : {} > INFOB

.infoC : {} > INFOC

.infoD : {} > INFOD

/* MSP430 INTERRUPT VECTORS */

.int00 : {} > INT00

.int01 : {} > INT01

.int02 : {} > INT02

.int03 : {} > INT03

.int04 : {} > INT04

.int05 : {} > INT05

.int06 : {} > INT06

.int07 : {} > INT07

.int08 : {} > INT08

.int09 : {} > INT09

.int10 : {} > INT10

.int11 : {} > INT11

.int12 : {} > INT12

.int13 : {} > INT13

.int14 : {} > INT14

.int15 : {} > INT15

.int16 : {} > INT16

.int17 : {} > INT17

.int18 : {} > INT18

.int19 : {} > INT19

.int20 : {} > INT20

.int21 : {} > INT21

.int22 : {} > INT22

.int23 : {} > INT23

.int24 : {} > INT24

.int25 : {} > INT25

.int26 : {} > INT26

.int27 : {} > INT27

.int28 : {} > INT28

.int29 : {} > INT29

.int30 : {} > INT30

.int31 : {} > INT31

.int32 : {} > INT32

.int33 : {} > INT33

.int34 : {} > INT34

.int35 : {} > INT35

.int36 : {} > INT36

.int37 : {} > INT37

.int38 : {} > INT38

.int39 : {} > INT39

.int40 : {} > INT40

RTC : { * ( .int41 ) } > INT41 type = VECT_INIT

PORT2 : { * ( .int42 ) } > INT42 type = VECT_INIT

.int43 : {} > INT43

.int44 : {} > INT44

USCI_B1 : { * ( .int45 ) } > INT45 type = VECT_INIT

USCI_A1 : { * ( .int46 ) } > INT46 type = VECT_INIT

PORT1 : { * ( .int47 ) } > INT47 type = VECT_INIT

TIMER1_A1 : { * ( .int48 ) } > INT48 type = VECT_INIT

TIMER1_A0 : { * ( .int49 ) } > INT49 type = VECT_INIT

DMA : { * ( .int50 ) } > INT50 type = VECT_INIT

.int51 : {} > INT51

.int52 : {} > INT52

TIMER0_A1 : { * ( .int53 ) } > INT53 type = VECT_INIT

TIMER0_A0 : { * ( .int54 ) } > INT54 type = VECT_INIT

ADC12 : { * ( .int55 ) } > INT55 type = VECT_INIT

USCI_B0 : { * ( .int56 ) } > INT56 type = VECT_INIT

USCI_A0 : { * ( .int57 ) } > INT57 type = VECT_INIT

WDT : { * ( .int58 ) } > INT58 type = VECT_INIT

TIMER0_B1 : { * ( .int59 ) } > INT59 type = VECT_INIT

TIMER0_B0 : { * ( .int60 ) } > INT60 type = VECT_INIT

UNMI : { * ( .int61 ) } > INT61 type = VECT_INIT

SYSNMI : { * ( .int62 ) } > INT62 type = VECT_INIT

.reset : {} > RESET /* MSP430 RESET VECTOR */

}

/****************************************************************************/

/* INCLUDE PERIPHERALS MEMORY MAP */

/****************************************************************************/

-l msp430f5418a.cmd

0 Katie Pier over 10 years ago in reply to Gerard van Leeuwen

TI__Guru 73236 points

Hi Gerard,

0x1980 is in INFO memory. If you are running the BSL in BSL memory, if code jumps out of the protected BSL memory then the BSL is exited. This is one reason why you cannot use interrupts in the BSL - because the interrupt vector table is outside of the protected BSL memory, it would cause you to jump out of the BSL. So you cannot use INFO memory to expand your BSL in this way.

If you need more space, what we've done on the USB BSL for example (if you look at the SLAA450 example code) is that we have a bare-bones loader only supporting load into RAM, that is used to load a full-featured larger bootloader into the RAM of the device. Then that full-featured bootloader runs from RAM. Perhaps this is something that you would want to explore, using the USB BSL as a guide (you basically build the same project a different way with a different linker file, to build the minimal flash BSL vs the full RAM BSL).

Regards,
Katie

0 Gerard van Leeuwen over 10 years ago in reply to Katie Pier

Intellectual 325 points

Hi Katie,

Ok this is undestandable. To try things out, I wrote a small application to test how I could use the information pages. I adapted a function to rewrite the infopages:

int write_segment(BYTE segment, char *data) // Segment 'A' .. 'D'

{

unsigned int i;

unsigned short w;

char * Flash_ptr;

if (segment <'A' || segment >'D')

return -1;

seri_tx_cr(); seri_puts("<Write:"); seri_put(segment); seri_put('>');

///////////////////////////////////

// segment A == 0x1980 .. 0x19FF //

// segment B == 0x1900 .. 0x197F //

// segment C == 0x1880 .. 0x18FF //

// segment D == 0x1800 .. 0x187F //

///////////////////////////////////

Flash_ptr = (char *) (0x1980 - ((segment-'A')*0x80));

__disable_interrupt(); // 5xx Workaround: Disable global

// interrupt while erasing. Re-Enable

// GIE if needed

FCTL3 = FWKEY; // Clear Lock bit

FCTL1 = FWKEY+ERASE; // Set Erase bit

*(unsigned int *)Flash_ptr = 0; // Dummy write to erase Flash seg

FCTL1 = FWKEY+WRT; // Set WRT bit for write operation

for (i = 0; i < 0x40; i++)

{

*Flash_ptr++ = *(data+1); // Write value to flash

*Flash_ptr++ = *data;

data+=2;

}

FCTL1 = FWKEY; // Clear WRT bit

FCTL3 = FWKEY+LOCK; // Set LOCK bit

__enable_interrupt();

return 0;

}

When I use this function I call it as follows:

write_segment('A', data_A);
write_segment('B', data_B);
write_segment('C', data_C);
write_segment('D', data_D);

Somehow segments B,C and D are working OK. But segment A I can not rewrite... Any idea what is my error in this?

0 Katie Pier over 10 years ago in reply to Gerard van Leeuwen

TI__Guru 73236 points

Hi Gerard,

The INFO A section is locked separately from the other segments with the LOCKA bit in FCTL3 register. You'll have to clear this bit to be able to erase and write to INFOA. See section 7.2.1 of www.ti.com/lit/pdf/slau208.

Regards,
Katie

0 Gerard van Leeuwen over 10 years ago in reply to Katie Pier

Intellectual 325 points

Aha Well that Will be a simpel adjustment. I will gave it a try tomorrowmorning!

0 Gerard van Leeuwen over 10 years ago in reply to Gerard van Leeuwen

Intellectual 325 points

Works fine Katie! Thanks!!

0 Jens-Michael Gross over 10 years ago in reply to Gerard van Leeuwen

Guru 227245 points

The boot code will only test the BSL in case of a BOR. That means power failure or RESET pin.
In case of a PUC (e.g. WDT reset) or POR (SVS failure), the BSL entry function is not called and the boot code will always start the application.
However, this should only happen when the application was already started once (which means the BSL has already verified it after power-on)

Regarding your other question, well, you can use any region you want. But some locations may already have some special meaning. So part of the BSL area contains the JTAG fuse, which is also checked by the boot code at startup. If you put code there, JTAG won't work anymore.
0x1980, however, is infoA memory. It has a special protection. If you want to put code there, you have to specifically allow this. (The flash controller has a special lock bit for INFOA, and most flashing software has n additional enable option you'll have to check)
Else the write is simply not performed and your code is missing.

0 Piyush Chande over 9 years ago in reply to Katie Pier

Prodigy 35 points

Thank You Katie Pier for the proper description of the BSL + App functioning and the usage of RESET Vector.
This article cleared all my doubts on how to use BSL and how to handle the RESET Vector being generated by BSL as well as Application code.

I had been working on the BSL for MSP430F6779 since 2 months and got confused with all the threads related to Bootloader, restriction of having Vector address of 16 bits , Interrupt Vector remapping, Moving Vector to RAM, etc.

With this article I feel there is no need of Vector Table remapping to another area in FLASH or RAM.

Hope I will complete my custom BSL soon now.

Regards,
Piyush Chande

0 Katie Pier over 9 years ago in reply to Piyush Chande

TI__Guru 73236 points

So glad to hear it was helpful for you!
-Katie

0 Jens-Michael Gross over 9 years ago in reply to Piyush Chande

Guru 227245 points

"got confused with all the threads related to Bootloader, restriction of having Vector address of 16 bits , Interrupt Vector remapping, Moving Vector to RAM, etc."

Basically, you got confused with the built-in BSL and implementing a custom BSL. For the built-in, nothing of this is required. Also for a simple replacement that resides in BSL FLASH (only available for F5x/F6x family).
But if you want to implement a bootloader that is persistent like the original one, but resides in main flash and/or uses interrupts, then you WILL need those things.

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

BSL BOOTLOADER MSP430F5418A