Creating a custom BSL for firmware update

Hi Roy,

One thing that may help is looking at this app note called MSP-BOOT: www.ti.com/lit/pdf/slaa600 It shows a method for making a main memory bootloader with optional dual-image support like you discuss. I think you may have to do this in main memory depending on how much protocol overhead you have for the bluetooth.

The best option of course would be to make a bootloader in the BSL memory, but that is only 2kB so it depends on how much handling you have to do. You could start with www.ti.com/lit/pdf/slaa450 code for F5438 UART BSL as an example and modify from there, but like I said, it's pretty tight space so if you have to do a lot of protocol handling for your bluetooth this might not fit and you'd have to use the main memory method I mentioned above.

Regards,

Katie

Hi Katie,

Thank you for your answer! I think i have to go with option one and use a dual-image support. We use the Bluetopia library for the Bluetooth part and with the other code the code size will get past de 2kB mark. Just a quick question: are the MSP430F5438A and MSP438F5436A compatible with the dual-image option. After aquick look in Slau600 is saw that the other Gvariant and the FlashRam varians are used. Is this option avaliable for other MSP's and then especcialy the 38 and 36 variants?

In the code of the demo program is see that the target device checks for a boot request, this request can be external by e.g. a button press but also from the application of the target device. This is don by checking if bit 0 is set of the StatCtrl register. To my understanding this is just a software variable and not "connected" to a hardware register? If this is not true i can find the right hardware register in de 38/36 datasheet. Do you know which hardware data register i need?

If the variable is just a software control byte(like it says in the code comments) then how do i actually tell the MSP to go to boot mode? Or is this just a  software function and not a hardware state?

I have talked to our hardware guys and they have connectet the RX and TX for the bluetooth to p9 pins, in the datasheet there is a BSL mention for pins 1.1 and 1.2. This means we can't go for option two with this pin layout?

Thank you for your help so far!

Hi Roy,

The method of MSP-BOOT is designed to be possible on any MSP430 device - G2xx and FR57xx are just the parts that were chosen as examples (particularly because those parts normally don't have a customizable BSL, so this is a question that comes up often for those parts). You should be able to use the same method on any MSP430 device however. The example is also for I2C but could be changed to use other interfaces. The app note in general is there to help you see how to do this main memory type of bootloader that you can then customize for your purposes.

Roy Stegers said:

In the code of the demo program is see that the target device checks for a boot request, this request can be external by e.g. a button press but also from the application of the target device. This is don by checking if bit 0 is set of the StatCtrl register. To my understanding this is just a software variable and not "connected" to a hardware register? If this is not true i can find the right hardware register in de 38/36 datasheet. Do you know which hardware data register i need?

You are correct, this is a software variable that has been designed to always be in the same location and can be referenced then by your main code or by your bootloader code. Your main code would implement whatever method you want to use to request BSL entry and then set this address and the BSL password, then reset the part using the watchdog - see the function TI_MSPBoot_JumpToBoot() for example in TI_MSPBoot_Mgr_Vectors_G2553.c. You could basically use this function to jump to bootloader mode - just call it from wherever in your main program you've determined you have met conditions that you want to bootload the part. In the example, this is done by checking if a particular button is pressed - see main.c in App1, where TI_MSPBoot_JumpToBoot() is called. I believe at reset/startup it also checks if there is a valid image present in the device, and if there is not (indicating an incomplete load or something) it also enters bootloader mode (see figure 3 of the app note).

Roy Stegers said:

I have talked to our hardware guys and they have connectet the RX and TX for the bluetooth to p9 pins, in the datasheet there is a BSL mention for pins 1.1 and 1.2. This means we can't go for option two with this pin layout?

The advantage of option 2 is that it has a hardware method of BSL entry that will work even if the part is blank (except protected BSL area) - it doesn't require anything in your main area of code for BSL entry - however it is limited in space that you can use (only 2k), so you can do more customization if you use option 1.

Regards,

Katie

Hi Katie,

Thank you for your answer again! Your feedback is really helpful! I have one more question, in SLAU600 page 34 a CRCGen430 generator tool is explained with the folowing:

CRCType = CRC16 or CRC8
InputFile = Input File in .txt format
OutputFile = Output File in .txt format
StartAddr = Start address in hexadecimal format
EndAddr = End address in hexadecimal format
CRCAddr = Address in hexadecimal format where CRC is stored

My question is what should the stardaddr, endaddr an crcadder be? Is the start and end addr the space defined in the flash memory for the app area or the download area? And the CRC addr is the address where the target device stores the crc check value (somewere in the bootspace, is this the best space?)

Thanks again for your feedback!

Hi Roy,

The StartAddr and EndAddr should be defined according to App Area.

As you mention, the CRCAddr is the address where the device stores the CRC check of such application, but it shouldn't reside inside the BootArea  since the actual value of the CRC will change depending on the application and BootArea can't be erased. The AppNote simply puts the CRC before the application.

For example, if your device has flash from 0x8000-0xFFFF and your bootloader resides in 0xE000-0xFFF,

- you have 0x6000 available for App+Download. You can divide it in 2*0x3000

- your App can reside in 0xB000-0xDFFF

- your Download Area can reside in 0x8000-0xAFFF

- You can reserve the first 2 bytes for the CRC, so the CRCAddr will be 0xB000

- Your StartAddr would then be 0xB002 and your EndAddr=0xDFFF

- Your application will always run from 0xB002-0xDFFF and the bootloader will use the CRC in 0xB000 to validate it. But when you download the image (including CRC+App), it will be downloaded to 0x8000-0xAFFF.

Regards,

Luis R

Hi Luis and Katie,

Thank you for  your answers! 

I have one more question related to MSPBoot, this is a seperate project, so i can't integrate it in my program(firmware) do i have to make a hex from it and write it to my boot section? This way i can actually switch by writing the app space?

So at any given time the MSP contains a boot "program" in the boot section and the firmware program?

The  STACK_INIT(). can you explain what this function does?

I have modifed the MSPBoot program for use with the MSP450F4536A. When i load this program in the MSP and call the following function:

void TI_MSPBoot_AppMgr_JumpToApp(void)

{

extern void TI_MSPBoot_MI_EraseAppDirect(uint8_t DownArea);
extern void TI_MSPBoot_MI_ReplaceApp(void);

// Check image in download area

// If Image is valid, erase current App
TI_MSPBoot_MI_EraseAppDirect(0);
// Replace current App by Image in Download Area
TI_MSPBoot_MI_ReplaceApp();

// Erase the image in Download Area
TI_MSPBoot_MI_EraseAppDirect(1);

PMMCTL0 = PMMPW | PMMSWBOR;
}

I overwrite (i think) this program, in the TI_MSPBoot_MI_EraseAppDirect(0) function. I think is written in Main bank A. How do i place the bootloader program in a other segment. The debugger freezes after a couple erase actions.

Many thanks for all the help so far!

Hi Katie, Luis and others ;),

I have made a demo program with for the launch pad with the MSP G2553. I have modified the MSPBoot, it contains a demo program in hex format. I used the txt2array perl tool. And put all segments in one array. I slithly modifiied te TI_MSPBoot_AppMgr_JumpToApp function. It has no CRC check because the hex file is in the program. It also doesn't erase the download space. 

void TI_MSPBoot_AppMgr_JumpToApp(void)
{
extern void TI_MSPBoot_MI_EraseAppDirect(uint8_t DownArea);
extern void TI_MSPBoot_MI_ReplaceApp(void);

// If Image is valid, erase current App
TI_MSPBoot_MI_EraseAppDirect(0);
// Replace current App by Image in Download Area
TI_MSPBoot_MI_ReplaceApp();

#if defined (HW_RESET_BOR)
// Force a Software BOR
PMMCTL0 = PMMPW | PMMSWBOR;
#else
// Force a PUC reset by writing incorrect Watchdog password
WDTCTL = 0xDEAD;
#endif
}

The main.c file is also a little diffrent, i added the array and placed the write and erase functions in the main to write the array. When i run te program, the debugger doesn't work, this also happes with the original MSPBoot. The program in the image simply blinks the led but this doesn't happen. Do you have any sugestions?

// Include files
//
#include "msp430.h"
#include "TI_MSPBoot_Common.h"
#include "TI_MSPBoot_CI.h"
#include "TI_MSPBoot_AppMgr.h"

// Image of program
const uint8_t gtest_0[] = {
0xb2,0x40,0x80,0x5a,0x20,0x01,0xd2,0xd3,0x22,0x00,0xd2,0xd3,0x21,0x00,0x0d,0x12,
0x0e,0x12,0x3d,0x40,0x44,0x28,0x1e,0x43,0x1d,0x83,0x0e,0x73,0xfd,0x23,0x0d,0x93,
0xfb,0x23,0x3e,0x41,0x3d,0x41,0x00,0x3c,0x03,0x43,0xd2,0xc3,0x21,0x00,0x0d,0x12,
0x0e,0x12,0x3d,0x40,0x44,0x28,0x1e,0x43,0x1d,0x83,0x0e,0x73,0xfd,0x23,0x0d,0x93,
0xfb,0x23,0x3e,0x41,0x3d,0x41,0x00,0x3c,0x03,0x43,0xd2,0xd3,0x21,0x00,0x0d,0x12,
0x0e,0x12,0x3d,0x40,0x44,0x28,0x1e,0x43,0x1d,0x83,0x0e,0x73,0xfd,0x23,0x0d,0x93,
0xfb,0x23,0x3e,0x41,0x3d,0x41,0x00,0x3c,0x03,0x43,0xd2,0xc3,0x21,0x00,0xcf,0x3f,
0x0a,0x12,0x09,0x12,0x3f,0x40,0x00,0x00,0x3f,0x90,0x01,0x00,0x19,0x28,0x3f,0x40,
0x00,0x00,0x3f,0x90,0x01,0x00,0x14,0x28,0x3a,0x40,0x00,0x00,0x3a,0x80,0x00,0x00,
0x3a,0x50,0x03,0x00,0x0a,0x11,0x0a,0x11,0x39,0x40,0x00,0x00,0x3c,0x49,0x7f,0x4c,
0x4f,0x4f,0x0f,0x5f,0x1f,0x4f,0x00,0x00,0x3d,0x49,0x8f,0x12,0x1a,0x83,0xf6,0x23,
0x3f,0x40,0x00,0x00,0x3f,0x90,0x00,0x00,0x08,0x24,0x3a,0x40,0x00,0x00,0x02,0x3c,
0x3f,0x4a,0x8f,0x12,0x3a,0x90,0x00,0x00,0xfb,0x23,0x30,0x40,0xf2,0xc0,0x31,0x40,
0x00,0x04,0xb0,0x12,0xfe,0xc0,0x0c,0x93,0x02,0x24,0xb0,0x12,0x70,0xc0,0x0c,0x43,
0xb0,0x12,0x00,0xc0,0xb0,0x12,0x02,0xc1,0x34,0x41,0x35,0x41,0x36,0x41,0x37,0x41,
0x38,0x41,0x39,0x41,0x3a,0x41,0x30,0x41,0x32,0xd0,0x10,0x00,0xfd,0x3f,0x1c,0x43,
0x30,0x41,0x03,0x43,0xff,0x3f,0xf8,0xc0,0xf8,0xc0,0xf8,0xc0,0xf8,0xc0,0xf8,0xc0,
0xf8,0xc0,0xf8,0xc0,0xf8,0xc0,0xf8,0xc0,0xf8,0xc0,0xf8,0xc0,0xf8,0xc0,0xce,0xc0,
};
static const unsigned long Adress = 0xC000;
int Temp = 0;

uint8_t TI_MSPBoot_MI_WriteByteDirect2(uint16_t addr, uint8_t data)
{
// Write directly to the corresponding area
FCTL3 = FWKEY;
FCTL1 = FWKEY+ WRT; // Enable flash write
*(unsigned char*)addr = data; // Write data to flash
FCTL1 = FWKEY; // Disable flash write
FCTL3 = FWKEY + LOCK;
return RET_OK;
}

uint8_t TI_MSPBoot_MI_EraseSectorDirect2(uint16_t addr)
{
// Erase the corresponding area
FCTL1 = FWKEY + ERASE; // Enable flash erase
#if (MCLK==1000000)
FCTL2 = FWKEY + FSSEL_2 + 2; // Flash timing setup (SMCLK/3) = 333.333Khz
#elif (MCLK==4000000)
FCTL2 = FWKEY + FSSEL_2 + 8; // Flash timing setup (SMCLK/9) = 444.444Khz
#elif (MCLK==8000000)
FCTL2 = FWKEY + FSSEL_2 + 16; // Flash timing setup (SMCLK/17) = 470.588Khz
#else
#error "Please define a valid MCLK or add configuration"
#endif
FCTL3 = FWKEY; // Disable lock
*(unsigned int *)addr = 0; // Dummy write to erase flash
FCTL1 = FWKEY;
FCTL3 = FWKEY+LOCK; // Diasble flash write

return RET_OK;
}

int WriteSectionIntr(unsigned long StartAddress, unsigned char value[], int SizeOfSection){

int Size = SizeOfSection;
int Index = 0;

FCTL3 = FWKEY; // Clear Lock bit

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

for(Index=0; Index < Size; Index++){

//__data20_write_char (StartAddress+Index, value[Index]);
TI_MSPBoot_MI_WriteByteDirect2(StartAddress+Index, value[Index]);

}

FCTL1 = FWKEY; // Clear WRT bit

FCTL3 = FWKEY + LOCK; // Set LOCK bit

return 0;
}

//
// Local function prototypes
//
static void clock_init(void);
static void HW_init(void);

/******************************************************************************
*
* @brief Main function
* - Initializes the MCU
* - Selects whether to run application or bootloader
* - If bootloader:
* - Initializes the peripheral interface
* - Waits for a command
* - Sends the corresponding response
* - If application:
* - Jump to application
*
* @note USI interrupts are enabled after this function
* @return none
*****************************************************************************/
int main_boot( void )
{
// Stop watchdog timer to prevent time out reset
WDTCTL = WDTPW + WDTHOLD;

/*
* Important Note:
* MSPBoot assumes that proper conditions are met when executing after reset.
* It’s important to remark that DCO must not be changed until VCC>=VCC(min),
* and a minimum of 2.2V is required for Flash Program/Erase operations.
* An optional software delay can be added for applications having a slow
* voltage ramp-up or an external voltage supervisor is suggested
*
*/
// __delay_cycles(10000); // Uncomment this line and adjust number of delay
// cycles according to the application voltage ramp

// Initialize MCU
HW_init();
clock_init();

// Erase before write
TI_MSPBoot_MI_EraseSectorDirect2(Adress);

// Write image of demo program in flash at at start of download area
if(WriteSectionIntr(Adress, (unsigned char *)gtest_0, 288) == 0){
Temp++;
}
else{
Temp--;
}

// If Packet indicates a jump to App
TI_MSPBoot_AppMgr_JumpToApp();

}

/******************************************************************************
*
* @brief Initializes the MSP430 Clock
*
* @return none
*****************************************************************************/
//inline static void clock_init(void)
static void clock_init(void)
{
#if (MCLK==1000000)
// Validate the calibration values (only in Debug)
ASSERT_H((CALBC1_1MHZ !=0xFF) && (CALDCO_1MHZ != 0xFF));

BCSCTL1 = CALBC1_1MHZ; // Set DCO to default of 1Mhz
DCOCTL = CALDCO_1MHZ;
#elif (MCLK==4000000)
// Validate the calibration values (only in Debug)
ASSERT_H((CALBC1_8MHZ !=0xFF) && (CALDCO_8MHZ != 0xFF));

BCSCTL1 = CALBC1_8MHZ; // Set DCO to default of 8Mhz
DCOCTL = CALDCO_8MHZ;
BCSCTL2 = DIVM_1 | DIVS_1; // MCLK/SMCLK = 8Mhz/2 = 4Mhz
#elif (MCLK==8000000)
// Validate the calibration values (only in Debug)
ASSERT_H((CALBC1_8MHZ !=0xFF) && (CALDCO_8MHZ != 0xFF));

BCSCTL1 = CALBC1_8MHZ; // Set DCO to default of 8Mhz
DCOCTL = CALDCO_8MHZ;
#else
#error "Please define a valid MCLK or add configuration"
#endif
BCSCTL3 = LFXT1S_2; // LFXT1 = VLO
IFG1 &= ~(OFIFG); // Clear OSCFault flag

}

/******************************************************************************
*
* @brief Initializes the basic MCU HW
*
* @return none
*****************************************************************************/
static void HW_init(void)
{
// Just initialize S2 button to force BSL mode
P1OUT |= BIT3;
P1REN |= BIT3;
// The following routines disable interrupts which are cleared by POR but
// not by a PUC. In G2xx, these are: Timers, CompA, ADC10
#ifdef HW_RESET_PUC
TA0CTL = 0x00;
#ifdef __MSP430_HAS_T1A3__
TA1CTL = 0x00;
#endif
#ifdef __MSP430_HAS_CAPLUS__
CACTL1 = 0x00;
#endif
#ifdef __MSP430_HAS_ADC10__
ADC10CTL0 = 0x00;
#endif
#endif
}

Hi Roy,

A lot of questions =). Let me try to answer what I can:

Roy Stegers said:

I have one more question related to MSPBoot, this is a seperate project, so i can't integrate it in my program(firmware) do i have to make a hex from it and write it to my boot section? This way i can actually switch by writing the app space?

Yes. Once your bootloader is ready, you generate the binaries and then you can download them via IAR, CCS or any other tool (MSP430 Flasher, FET-Pro 430, etc). 

You can keep working and debugging your application while the bootloader is present but make sure you don't erase/overwrite it. And things can get tricky if you are validating the application and if you don't have a CRC. The application might work once when you download it, but then it will fail if you try resetting the device. 

As you saw, the AppNote includes a CRCGen, but if you are using IAR, you could generate the CRC automatically. Unfortunately, CCS doesn't have this option and that's why the AppNote has a separate tool to do it.

Roy Stegers said:

So at any given time the MSP contains a boot "program" in the boot section and the firmware program?

Correct. The device should at least have the bootloader at any given time. If there's no App, the bootloader can be used to download a new App.

Roy Stegers said:

The  STACK_INIT(). can you explain what this function does?

This line initializes the Stack Pointer.

Roy Stegers said:

You need to modify the linker file. In CCS, the file is .CMD while in IAR, it will be the .xcl

The main.c file is also a little diffrent, i added the array and placed the write and erase functions in the main to write the array. When i run te program, the debugger doesn't work, this also happes with the original MSPBoot. The program in the image simply blinks the led but this doesn't happen. Do you have any sugestions?

If I understand correctly, you are embedding the application image inside your bootloader and this bootloader simply rewrites the application everytime it executes and then jumps to it. Is that correct?

Is this running on F5438A or G2553? Note that in the G2xx3 the bootloader uses part of info memory, so you need to enable this option (project->Options->Debugger->FET Debugger->Download->Erase main and Information Memory).

Do you know where bootloader is located? 

And what is the actual address used by the application. I see that your array starts at 0xC000, but you are downloading directly to this address and then calling TI_MSPBoot_AppMgr_JumpToApp(). 

I can take a closer look at your projects if you can share them.

Regards,

Luis R

Hi Luis,

Thanks again for your feedback! I'm using CCS as IDE, the program above is made for the G2553 on the launch pad. It has a demo program loaded in the program as a byte array. I have also a bootloader made for the F4536, with the same problem. Can I send you this one? via e-mail? And would you take a look at it? I can also send you the g2553 variant. Both are test programs to get familiar with the bootloader and the dual image option.

The functionality of both programs is to start the booth loader and then write the program that is stored in the byte array to the app space and then reset the device and boot up the main program. Eventualy I want to use the Bluetooth module to download the new firmware (on run time of the old firmware), then reboot and then update, this is a step before the actual goal. 

When I run the perl script to array the scipts puts several arrays as output, I have combined these arrays to one big array, is this a problem ( is there a special purpose for this deviding)?  So output[0] and output[1] becomes one output array.

Do you know where bootloader is located? 

And what is the actual address used by the application. I see that your array starts at 0xC000, but you are downloading directly to this address and then calling TI_MSPBoot_AppMgr_JumpToApp().

I think this is the problem, how can I say where to put the bootloader when downloading it to the MSP? Where and how do I say this in the (linkerfile?).

For both programs I erase the main, info and protected memory hwen downloading the project code to the MSP.

Let me know how I can send my code (via e-mail? I can send this on Monday when have access to my code again, I'm a way for the weekend.), and many thanks for all your help so far! You and Katie have been both of great help!

Hi Luis,

I have send you a friend request for sending you my project so that you can take a look.

Below is my code of main_boot (for the msp5438A on the expirimenter board), it writes a the image (that is in a static array) to the flash and then calls the TI_MSPBoot_AppMgr_JumpToApp() function to write it to the app area, after this it resets. The TI_MSPBoot_AppMgr_JumpToApp() code is below the main_boot code.

When the system resets the program is not started, instead the bootloader is started (the debugger points to the STACK_INIT function). Do you or somebody else have a sugestion.

int main_boot( void )
{
// Stop watchdog timer to prevent time out reset
WDTCTL = WDTPW + WDTHOLD;

// Initialize MCU
HW_init();
clock_init();

// Will be set after the end of the TI_MSPBoot_AppMgr_JumpToApp function
// just before the BOR
if (StatCtrl == 1){
TI_MSPBoot_APPMGR_JUMPTOAPP();
}

/* Download area : 5C00-6BFF*/
/* App area: 6C00-FBFF*/
/* Boot area : FC00-FFFF*/

TI_MSPBoot_MI_EraseSectorDirect2(0x5C00);
TI_MSPBoot_MI_EraseSectorDirect2(0x5C00+512);
TI_MSPBoot_MI_EraseSectorDirect2(0x5C00+1024);

// Write to image to download area
WriteSectionIntr((unsigned long)0x5C00, input430f4538A_0, 188);
WriteSectionIntr((unsigned long)(0x5C00+512), input430f4538A_1, 46);

// Validate the application and jump if needed
//if (TI_MSPBoot_AppMgr_ValidateApp() == TRUE_t)
// TI_MSPBoot_APPMGR_JUMPTOAPP();

// If Packet indicates a jump to App
TI_MSPBoot_AppMgr_JumpToApp();

return 0;
}

void TI_MSPBoot_AppMgr_JumpToApp(void)
{

extern uint8_t StatCtrl;
// Check image in download area
//WATCHDOG_FEED();

// If Image is valid, erase current App
TI_MSPBoot_MI_EraseAppDirect(0);

// Replace current App by Image in Download Area
TI_MSPBoot_MI_ReplaceApp();

// Erase the image in Download Area
TI_MSPBoot_MI_EraseAppDirect(1);

//TI_MSPBoot_APPMGR_JUMPTOAPP();

StatCtrl = 1;

// Force a Software BOR
PMMCTL0 = PMMPW | PMMSWBOR;

}

Hi there,

How do I share interrupt routine between app. and boot loader?. (Both app and boot loader uses same interrupt for operation).

Thanks in advance,

Rahul

Hi Rahul,

MSPBoot (SLAA600) has an interrupt vector redirection in software but it doesn't share vectors since the bootloader is polling-based.

It's possible to do it though.

- One approach could be to simply use a global shared variable which indicates if you are in bootloader or in Application. Depending on the variable, you would jump to one vector or another. This has to be implemented in Software and it will add latency.

- Another similar approach could be to use a pointer to function. A RAM pointer points to the corresponding ISR. By default, the bootloader loads it with the vector of the Bootloader ISR, but the vector is modified by the application. This has to be implemented in SW too and it will also add latency. 

- If using F5xx, it might be good to use Hardware vector redirection which moves the vectors to RAM. This is a hardware solution.

- If using FRAM, the vector could be modified directly by the bootloader and the application. This is also a hardware solution.

If the application doesn't set the vector properly, you could end up with a device jumping to invalid vector, but if we assume that the bootloader will always be available, then we can assume that it would restore the vector at least for proper bootloader functionality. 

Regards,

Luis R

Thank Luis.

I'm using CC430F5137, can you guide me how to achieve Hardware Vector Redirection ?

Thanks,

Rahul

You can enable it by setting SYSCTL.SYSRIVECT=1.

The reset vectors are always at the top of 64K Flash (i.e. Reset=0xFFFE) after Reset, but if you set this bit to 1, then the vectors will be mapped to the top of RAM.

Make sure you disable interrupts, then copy/write all the vectors in RAM, then set the bit to '1'

This bit is explained in the User's Guide SLAU259 http://www.ti.com/lit/pdf/slau259

Regards,

Luis R

Thank you Luis. I'll look into that.

Thanks,

Rahul

 1.     In project properties under Debug > MSP430 Properties > Download Options, I selected "Erase main, information, and protected information memory" and enabled "Allow Read/Write/Erase access to BSL memory"2.   Under Build > Steps tab > Apply Predefined Step we selected "Create Flash image TI-TXT"

But I found that the linker script in the example was for 5418A board and not for 5438A. So I changed the device in Project properties > General > Device to 5438A.

04 3C FE 3F FF 3F FF 3F FF 3F 30 40 00 5C 08 08 
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 FF FF 
2A 00 A5 3C 5A C3 FF FF 00 00 FF FF FF FF 04 00 
@5c00
31 40 00 5C 00 18 F2 40 36 63 0E 1D 00 18 F2 40 
36 63 12 1D B0 13 20 63 0C 43 B0 13 22 5C B0 13 
32 63 5A 14 0E 41 3E 80 00 1C 3F 40 FE 1B 0F 5E 
8F 43 00 00 2F 83 2E 83 FB 23 82 43 1E 1D B2 40 
00 A5 20 1D B2 40 0A 1C 04 1C B2 40 0A 1C 06 1C 
B2 40 41 03 00 1C B2 40 A0 01 02 1C 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 B2 40 20 00 42 03 B2 40 20 02 
40 03 F2 40 06 00 0A 02 E2 43 04 02 3A 40 3B 00 
39 40 3A 00 38 40 05 00 37 40 07 00 35 40 4F 00 
06 43 97 3C B2 90 A5 A5 1E 1D 4F 20 0F 18 4D 5D 
00 18 4D DC 4D 13 4C 43 85 3C 5F 4B 04 00 5E 4B 
05 00 47 18 0E 5E 0E DF B2 43 54 01 0B 43 0E 5C 
0B 6D 0D 3C B2 90 A5 A5 1E 1D 21 20 CF 0D 0F 18 
4F 5F 00 18 4F DC E2 4F 52 01 1C 53 0D 63 0D 9B 
F1 2B 02 20 0C 9E EE 2B 1F 42 54 01 1E 42 06 1C 
CE 49 00 00 1E 42 06 1C CE 4F 01 00 8F 10 8F 11 
1E 42 06 1C CE 4F 02 00 3C 40 03 00 58 3C B0 13 
58 5E EF 42 01 00 52 3C B2 90 A5 A5 1E 1D 0D 20 
3F 40 10 00 1F F2 44 01 1F 52 20 1D 3F 50 40 00 
18 3C B2 90 A5 A5 1E 1D 02 24 6C 42 3B 3C 92 42 
20 1D 44 01 2F 43 1F 52 20 1D 82 4F 40 01 0F 18 
4D 5D 00 18 4D DC CD 43 00 00 3F 40 10 00 1F 52 
20 1D 82 4F 44 01 9F 3F CC 0F B0 13 76 62 4C 93 
05 20 B0 13 58 5E CF 43 01 00 20 3C B0 13 58 5E 
CF 48 01 00 1B 3C B0 13 58 5E CF 47 01 00 16 3C 
5F 43 53 3C 2E 42 CC 05 CD 06 07 3C 5E 4B 04 00 
5F 4B 05 00 47 18 0F 5F 0E DF B0 13 22 61 09 3C 
B0 13 F6 62 B0 13 58 5E CF 4C 01 00 2C 43 B0 13 
2E 62 B0 13 66 5E 5C B3 FC 27 1F 43 1F 52 04 1C 
1E 42 04 1C 5C 4E 03 00 0D 43 B0 13 D4 62 1E 42 
04 1C 5E 4E 02 00 0C DE B0 13 D4 62 6E 4F 0C DE 
1B 42 04 1C 6E 4B 3E 80 10 00 3E 90 0C 00 C3 2F 
5E 06 00 18 50 4E 18 5E 48 5E 00 00 78 5D 00 00 
42 5D 00 00 28 5D 00 00 96 5D 00 00 C0 5D 00 00 
BA 5C 00 00 A4 5C 00 00 AC 5D 00 00 A4 5D 00 00 
96 5D 00 00 A0 5D 00 00 4F 43 2E 42 1E 52 04 1C 
B0 13 08 60 BE 3F 03 43 1F 42 06 1C CF 4A 00 00 
1F 42 06 1C 10 01 21 83 81 43 00 00 4D 43 0C 43 
45 3C F2 90 52 00 0A 1C 3D 20 5F 42 0B 1C 2F 83 
31 24 1F 83 26 24 1F 83 1B 24 1F 83 10 24 1F 83 
05 24 7C 40 56 00 B0 13 E0 61 2C 3C B0 13 00 60 
B2 40 45 00 00 1C B2 40 22 00 02 1C 23 3C B0 13 
00 60 B2 40 8A 00 00 1C B2 40 45 00 02 1C 1A 3C 
B0 13 00 60 B2 40 D0 00 00 1C B2 40 68 00 02 1C 
11 3C B0 13 00 60 B2 40 A0 01 00 1C B2 40 D0 00 
02 1C 08 3C B0 13 00 60 B2 40 41 03 00 1C B2 40 
A0 01 02 1C 81 43 00 00 4D 43 0C 43 B2 40 20 89 
44 03 92 B3 44 03 FD 27 B2 F0 FE FE 44 03 92 52 
02 1C 54 03 3E 40 09 00 0F 43 92 52 00 1C 54 03 
92 C3 44 03 92 B3 44 03 FD 27 5F 01 B2 B0 00 04 
44 03 02 24 3F D0 00 01 1E 83 EF 23 4F 4F 0C 93 
09 20 3F 90 80 00 3A 24 7C 40 51 00 6D 43 B0 13 
E0 61 53 3C 1C 93 4C 24 2C 93 32 24 CE 0C 1E 82 
08 1C 3E 90 03 00 28 24 2E 92 23 20 4F 4F 8F 10 
81 DF 00 00 2D 41 B2 43 54 01 82 93 08 1C 09 24 
3E 40 0A 1C 0F 43 F2 4E 52 01 1F 53 1F 92 08 1C 
FA 2B 82 9D 54 01 0A 20 5F 42 0A 1C 3F F0 F0 FF 
3F 90 50 00 66 27 4C 43 5D 43 D1 3F 7C 40 52 00 
CD 3F CC 4F 07 1C 02 3C 81 4F 00 00 1C 53 1B 3C 
4F 4F 8F 10 82 DF 08 1C 82 93 08 1C 05 20 7C 40 
53 00 B0 13 E0 61 6D 43 B2 90 05 01 08 1C 05 28 
7C 40 54 00 B0 13 E0 61 6D 43 3C 40 03 00 03 3C 
82 4F 08 1C 2C 43 4D 93 81 27 CC 0D 21 53 10 01 
4C 43 B0 13 E0 61 10 01 6A 14 B2 90 A5 A5 1E 1D 
02 24 6B 42 0A 3C 92 42 20 1D 44 01 3B 40 40 00 
1B 52 20 1D 82 4B 40 01 4B 43 0A 43 B2 90 05 00 
08 1C 01 28 1A 43 09 43 4B 93 01 20 19 43 09 BA 
51 24 1A 42 08 1C 2A 82 C6 0C C5 0D C8 0A 09 43 
08 56 09 65 05 99 05 28 02 20 06 98 02 28 4B 43 
41 3C 17 43 07 FC 07 93 20 20 C4 06 CB 05 04 8A 
0B 73 04 8C 0B 7D 3B 93 02 20 34 93 16 24 24 4E 
B2 90 A5 A5 1E 1D 0C 20 B0 13 16 61 8B 44 00 00 
B0 13 16 61 24 9B 02 20 4B 43 03 3C 5B 43 01 3C 
6B 42 2E 53 16 53 05 63 14 3C 64 4E B2 90 A5 A5 
1E 1D 0D 20 B0 13 16 61 CB 44 00 00 B0 13 16 61 
6B 4B 44 9B 02 20 4B 43 03 3C 5B 43 01 3C 6B 42 
1E 53 4B 93 07 20 16 53 05 63 05 99 C4 2B 02 20 
06 98 C1 2B 4F 93 0C 20 1F 42 06 1C FF 40 3B 00 
00 00 1F 42 06 1C CF 4B 01 00 2C 43 B0 13 2E 62 
92 42 20 1D 40 01 3F 40 10 00 1F 52 20 1D 82 4F 
44 01 64 16 10 01 CB 05 0F 18 4B 5B 00 18 4B D6 
10 01 6A 14 C9 0C CA 0D 07 43 C6 0E 06 59 07 6A 
45 43 49 3C CF 06 CE 07 0F 89 0E 7A 05 20 3F 90 
04 01 02 2C C8 0F 02 3C 38 40 03 01 15 43 15 52 
06 1C CF 09 CE 0A 0F 58 0E 63 1F 83 0E 73 0E 9A 
26 28 02 20 0F 99 23 28 34 40 3B 00 B2 90 A5 A5 
1E 1D 12 20 CB 0F 0B 89 0B 55 CC 0E 0F 18 4C 5C 
00 18 4C DF EB 4C 00 00 1F 83 0E 73 0E 9A 0F 28 
ED 23 0F 99 EB 2F 0B 3C 1F 42 06 1C CF 44 00 00 
1F 42 06 1C EF 42 01 00 2C 43 65 42 08 3C 1F 42 
06 1C FF 40 3A 00 00 00 1C 43 0C 58 45 43 B0 13 
2E 62 09 58 0A 63 0F 43 0A 97 04 28 02 20 09 96 
01 28 1F 43 45 45 05 DF 05 93 AC 27 64 16 10 01 
92 42 50 03 52 03 92 52 00 1C 52 03 4C 4C 3C 50 
00 02 5C 02 3F 40 00 02 3E 40 0B 00 92 B3 42 03 
FD 27 92 C3 42 03 92 52 00 1C 52 03 B2 D0 80 00 
42 03 1C B3 04 24 0C EF B2 F0 7F FF 42 03 5F 01 
5C 01 1E 83 EB 23 92 B3 42 03 FD 27 10 01 CD 0C 
7C 40 80 00 B0 13 E0 61 B0 13 66 62 B0 13 E0 61 
B2 43 54 01 1D 93 09 38 3B 40 0A 1C 7C 4B C2 4C 
52 01 B0 13 E0 61 1D 83 F9 23 1D 42 54 01 B0 13 
66 62 80 00 E0 61 4C 4D B0 13 E0 61 CC 0D 8C 10 
8C 11 4C 4C 10 01 21 83 3D 40 20 00 0E 43 3B 40 
E0 FF 7F 4C 7F EB 0E DF 1D 83 FB 23 0E 93 05 24 
B0 13 F6 62 7C 40 05 00 0D 3C B1 40 FF 7F 00 00 
02 3C 91 83 00 00 91 93 00 00 FB 37 B2 40 A5 A5 
1E 1D 4C 43 21 53 10 01 5C 02 0D 6D 5C 02 0D 6D 
5C 02 0D 6D 5C 02 0D 6D 5C 02 0D 6D 5C 02 0D 6D 
5C 02 0D 6D 5C 02 0D 6D 5C 02 0D 6D 5C 02 0D 6D 
5C 02 0D 6D 5C 02 0D 6D 5C 02 0D 6D 5C 02 0D 6D 
5C 02 0D 6D 10 01 92 42 20 1D 44 01 3F 40 06 00 
1F 52 20 1D 82 4F 40 01 3F 40 E0 FF CF 43 00 00 
3F 40 10 00 1F 52 20 1D 82 4F 44 01 4C 43 10 01 
B2 40 80 5A 5C 01 32 C2 03 43 10 01 32 D0 10 00 
FD 3F 03 43 FF 3F 10 01 
@ffd2
2C 63 2C 63 2C 63 2C 63 2C 63 2C 63 2C 63 2C 63 
2C 63 2C 63 2C 63 2C 63 2C 63 2C 63 2C 63 2C 63 
2C 63 2C 63 2C 63 2C 63 2C 63 2C 63 00 5C 
q

Hi Ranganathan,

The BSL uses a special modified version of the linker file to ensure that all of the BSL code gets put into the correct places within the BSL area - you can take a look at this linker file included with the BSL, and you'll see it has some more sections defined that are not in the default linker files. I suspect what happened here is that when you changed the device to F5438A, CCS changed to using the default linker file for F5438A, which does not have these BSL modifications. This is why you are seeing that the code was not put correctly into the BSL area.

The reason the code was for F5418A I believe is that all the BSL releases always use the memory map of the smallest family variant, to ensure that everything fits in all of the variants of the part, though if you are just using BSL area this shouldn't matter since the variants will all be the same in this respect.

So you have a couple of options:

-leave the project as using F5418A and using the modified linker file for F5418A that came with the BSL code. I believe CCS error message that it will give you when loading the part is just a warning and will allow you to proceed loading the code even though it is for a smaller variant.

-or you could do a file comparison and apply the changes from the F5418A modified BSL linker file and apply them to the F5438A linker file. I would actually consider this more risky however, as it would be easy to miss something or make a mistake transcribing these changes over. It would be better to just use the F5418A linker file - since it is just using the BSL area that is the same on both devices, there's not a risk here (and it is pretty standard for all of our BSL source code to do this).

Regards,

Katie

Hi Katie,

I tried to do so as you mentioned. I ignored the warning and proceeded with flashing. The flashing was successful.

But after resetting the board, it didn't boot up. The board looks dead and none of the default LEDs are glowing.

Kindly help us on this issue.

Regards,

Ranganathan

Hi Ranganathan,

If you have only loaded the BSL starting at 0x1000 and the rest of the part is blank, nothing is going to happen at startup. You need to provide the BSL entry sequence on RST and TEST as detailed in www.ti.com/lit/pdf/slau319 - you can do this using a Launchpad by following this app note www.ti.com/lit/pdf/slaa535 and code www.ti.com/lit/zip/slaa535 with the BSL Scripter.

If you load another code project, like a blinking LED, into the main area of the device, it should run normally. But I suspect right now your main code area is blank and you have only loaded BSL? In this case you won't see anything happen after reset because there is no main code in the part to be run.

Regards,

Katie

Hi Katie,

I agree that the application/main area will be blank. But when i try to load the sample LED application with the FET, it is showing the following error "MSP430: Error connecting to the target: Unknown device". The same FET is able to communicate with the other targets.

Please help on the same.

Regards,
Ranganathan

So you switched back to building from F5418A - did you also return to using the custom BSL zip file that includes sections like "ZAREA" etc?

How did your TI-TXT file that was generated look ?

Regards,

Katie

Hi Katie,

I am building the the example source downloaded from TI website (which contains f5418a.cmd) and flashing on my F5438A. Yes it has sections like ZAREA. I have attached the generated TI-TXT file for your reference.

Please clarify me on the below doubts:

1. If the BSL is not proper, is it not possible to communicate to MSP430 via JTAG using the FET?

2. If the BSL is programmed wrongly or if it is corrupted, is there is way to recover the same?

@1000
04 3C FE 3F FF 3F FF 3F FF 3F 30 40 42 10 
@1010
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 00 18 F2 40 78 17 0E 1D 00 18 
F2 40 78 17 12 1D B0 13 62 17 0C 43 B0 13 64 10 
B0 13 74 17 5A 14 0E 41 3E 80 00 1C 3F 40 FE 1B 
0F 5E 8F 43 00 00 2F 83 2E 83 FB 23 82 43 1E 1D 
B2 40 00 A5 20 1D B2 40 0A 1C 04 1C B2 40 0A 1C 
06 1C B2 40 41 03 00 1C B2 40 A0 01 02 1C 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 B2 40 20 00 42 03 B2 40 
20 02 40 03 F2 40 06 00 0A 02 E2 43 04 02 3A 40 
3B 00 39 40 3A 00 38 40 05 00 37 40 07 00 35 40 
10 10 06 43 97 3C B2 90 A5 A5 1E 1D 4F 20 0F 18 
4D 5D 00 18 4D DC 4D 13 4C 43 85 3C 5F 4B 04 00 
5E 4B 05 00 47 18 0E 5E 0E DF B2 43 54 01 0B 43 
0E 5C 0B 6D 0D 3C B2 90 A5 A5 1E 1D 21 20 CF 0D 
0F 18 4F 5F 00 18 4F DC E2 4F 52 01 1C 53 0D 63 
0D 9B F1 2B 02 20 0C 9E EE 2B 1F 42 54 01 1E 42 
06 1C CE 49 00 00 1E 42 06 1C CE 4F 01 00 8F 10 
8F 11 1E 42 06 1C CE 4F 02 00 3C 40 03 00 58 3C 
B0 13 9A 12 EF 42 01 00 52 3C B2 90 A5 A5 1E 1D 
0D 20 3F 40 10 00 1F F2 44 01 1F 52 20 1D 3F 50 
40 00 18 3C B2 90 A5 A5 1E 1D 02 24 6C 42 3B 3C 
92 42 20 1D 44 01 2F 43 1F 52 20 1D 82 4F 40 01 
0F 18 4D 5D 00 18 4D DC CD 43 00 00 3F 40 10 00 
1F 52 20 1D 82 4F 44 01 9F 3F CC 0F B0 13 B8 16 
4C 93 05 20 B0 13 9A 12 CF 43 01 00 20 3C B0 13 
9A 12 CF 48 01 00 1B 3C B0 13 9A 12 CF 47 01 00 
16 3C 5F 43 53 3C 2E 42 CC 05 CD 06 07 3C 5E 4B 
04 00 5F 4B 05 00 47 18 0F 5F 0E DF B0 13 64 15 
09 3C B0 13 38 17 B0 13 9A 12 CF 4C 01 00 2C 43 
B0 13 70 16 B0 13 A8 12 5C B3 FC 27 1F 43 1F 52 
04 1C 1E 42 04 1C 5C 4E 03 00 0D 43 B0 13 16 17 
1E 42 04 1C 5E 4E 02 00 0C DE B0 13 16 17 6E 4F 
0C DE 1B 42 04 1C 6E 4B 3E 80 10 00 3E 90 0C 00 
C3 2F 5E 06 00 18 50 4E 5A 12 8A 12 00 00 BA 11 
00 00 84 11 00 00 6A 11 00 00 D8 11 00 00 02 12 
00 00 FC 10 00 00 E6 10 00 00 EE 11 00 00 E6 11 
00 00 D8 11 00 00 E2 11 00 00 4F 43 2E 42 1E 52 
04 1C B0 13 4A 14 BE 3F 03 43 1F 42 06 1C CF 4A 
00 00 1F 42 06 1C 10 01 21 83 81 43 00 00 4D 43 
0C 43 45 3C F2 90 52 00 0A 1C 3D 20 5F 42 0B 1C 
2F 83 31 24 1F 83 26 24 1F 83 1B 24 1F 83 10 24 
1F 83 05 24 7C 40 56 00 B0 13 22 16 2C 3C B0 13 
42 14 B2 40 45 00 00 1C B2 40 22 00 02 1C 23 3C 
B0 13 42 14 B2 40 8A 00 00 1C B2 40 45 00 02 1C 
1A 3C B0 13 42 14 B2 40 D0 00 00 1C B2 40 68 00 
02 1C 11 3C B0 13 42 14 B2 40 A0 01 00 1C B2 40 
D0 00 02 1C 08 3C B0 13 42 14 B2 40 41 03 00 1C 
B2 40 A0 01 02 1C 81 43 00 00 4D 43 0C 43 B2 40 
20 89 44 03 92 B3 44 03 FD 27 B2 F0 FE FE 44 03 
92 52 02 1C 54 03 3E 40 09 00 0F 43 92 52 00 1C 
54 03 92 C3 44 03 92 B3 44 03 FD 27 5F 01 B2 B0 
00 04 44 03 02 24 3F D0 00 01 1E 83 EF 23 4F 4F 
0C 93 09 20 3F 90 80 00 3A 24 7C 40 51 00 6D 43 
B0 13 22 16 53 3C 1C 93 4C 24 2C 93 32 24 CE 0C 
1E 82 08 1C 3E 90 03 00 28 24 2E 92 23 20 4F 4F 
8F 10 81 DF 00 00 2D 41 B2 43 54 01 82 93 08 1C 
09 24 3E 40 0A 1C 0F 43 F2 4E 52 01 1F 53 1F 92 
08 1C FA 2B 82 9D 54 01 0A 20 5F 42 0A 1C 3F F0 
F0 FF 3F 90 50 00 66 27 4C 43 5D 43 D1 3F 7C 40 
52 00 CD 3F CC 4F 07 1C 02 3C 81 4F 00 00 1C 53 
1B 3C 4F 4F 8F 10 82 DF 08 1C 82 93 08 1C 05 20 
7C 40 53 00 B0 13 22 16 6D 43 B2 90 05 01 08 1C 
05 28 7C 40 54 00 B0 13 22 16 6D 43 3C 40 03 00 
03 3C 82 4F 08 1C 2C 43 4D 93 81 27 CC 0D 21 53 
10 01 4C 43 B0 13 22 16 10 01 6A 14 B2 90 A5 A5 
1E 1D 02 24 6B 42 0A 3C 92 42 20 1D 44 01 3B 40 
40 00 1B 52 20 1D 82 4B 40 01 4B 43 0A 43 B2 90 
05 00 08 1C 01 28 1A 43 09 43 4B 93 01 20 19 43 
09 BA 51 24 1A 42 08 1C 2A 82 C6 0C C5 0D C8 0A 
09 43 08 56 09 65 05 99 05 28 02 20 06 98 02 28 
4B 43 41 3C 17 43 07 FC 07 93 20 20 C4 06 CB 05 
04 8A 0B 73 04 8C 0B 7D 3B 93 02 20 34 93 16 24 
24 4E B2 90 A5 A5 1E 1D 0C 20 B0 13 58 15 8B 44 
00 00 B0 13 58 15 24 9B 02 20 4B 43 03 3C 5B 43 
01 3C 6B 42 2E 53 16 53 05 63 14 3C 64 4E B2 90 
A5 A5 1E 1D 0D 20 B0 13 58 15 CB 44 00 00 B0 13 
58 15 6B 4B 44 9B 02 20 4B 43 03 3C 5B 43 01 3C 
6B 42 1E 53 4B 93 07 20 16 53 05 63 05 99 C4 2B 
02 20 06 98 C1 2B 4F 93 0C 20 1F 42 06 1C FF 40 
3B 00 00 00 1F 42 06 1C CF 4B 01 00 2C 43 B0 13 
70 16 92 42 20 1D 40 01 3F 40 10 00 1F 52 20 1D 
82 4F 44 01 64 16 10 01 CB 05 0F 18 4B 5B 00 18 
4B D6 10 01 6A 14 C9 0C CA 0D 07 43 C6 0E 06 59 
07 6A 45 43 49 3C CF 06 CE 07 0F 89 0E 7A 05 20 
3F 90 04 01 02 2C C8 0F 02 3C 38 40 03 01 15 43 
15 52 06 1C CF 09 CE 0A 0F 58 0E 63 1F 83 0E 73 
0E 9A 26 28 02 20 0F 99 23 28 34 40 3B 00 B2 90 
A5 A5 1E 1D 12 20 CB 0F 0B 89 0B 55 CC 0E 0F 18 
4C 5C 00 18 4C DF EB 4C 00 00 1F 83 0E 73 0E 9A 
0F 28 ED 23 0F 99 EB 2F 0B 3C 1F 42 06 1C CF 44 
00 00 1F 42 06 1C EF 42 01 00 2C 43 65 42 08 3C 
1F 42 06 1C FF 40 3A 00 00 00 1C 43 0C 58 45 43 
B0 13 70 16 09 58 0A 63 0F 43 0A 97 04 28 02 20 
09 96 01 28 1F 43 45 45 05 DF 05 93 AC 27 64 16 
10 01 92 42 50 03 52 03 92 52 00 1C 52 03 4C 4C 
3C 50 00 02 5C 02 3F 40 00 02 3E 40 0B 00 92 B3 
42 03 FD 27 92 C3 42 03 92 52 00 1C 52 03 B2 D0 
80 00 42 03 1C B3 04 24 0C EF B2 F0 7F FF 42 03 
5F 01 5C 01 1E 83 EB 23 92 B3 42 03 FD 27 10 01 
CD 0C 7C 40 80 00 B0 13 22 16 B0 13 A8 16 B0 13 
22 16 B2 43 54 01 1D 93 09 38 3B 40 0A 1C 7C 4B 
C2 4C 52 01 B0 13 22 16 1D 83 F9 23 1D 42 54 01 
B0 13 A8 16 80 00 22 16 4C 4D B0 13 22 16 CC 0D 
8C 10 8C 11 4C 4C 10 01 21 83 3D 40 20 00 0E 43 
3B 40 E0 FF 7F 4C 7F EB 0E DF 1D 83 FB 23 0E 93 
05 24 B0 13 38 17 7C 40 05 00 0D 3C B1 40 FF 7F 
00 00 02 3C 91 83 00 00 91 93 00 00 FB 37 B2 40 
A5 A5 1E 1D 4C 43 21 53 10 01 5C 02 0D 6D 5C 02 
0D 6D 5C 02 0D 6D 5C 02 0D 6D 5C 02 0D 6D 5C 02 
0D 6D 5C 02 0D 6D 5C 02 0D 6D 5C 02 0D 6D 5C 02 
0D 6D 5C 02 0D 6D 5C 02 0D 6D 5C 02 0D 6D 5C 02 
0D 6D 5C 02 0D 6D 10 01 92 42 20 1D 44 01 3F 40 
06 00 1F 52 20 1D 82 4F 40 01 3F 40 E0 FF CF 43 
00 00 3F 40 10 00 1F 52 20 1D 82 4F 44 01 4C 43 
10 01 B2 40 80 5A 5C 01 32 C2 03 43 10 01 32 D0 
10 00 FD 3F 03 43 FF 3F 10 01 
@17f0
FF FF 2E 10 A5 3C 5A C3 FF FF 00 10 FF FF FF FF 
@ffd2
6E 17 6E 17 
@ffda
6E 17 6E 17 6E 17 6E 17 6E 17 6E 17 
@ffea
6E 17 6E 17 6E 17 6E 17 6E 17 6E 17 6E 17 6E 17 
6E 17 6E 17 42 10 
q

Regards,
Ranga

Hi Ranga,

Ranganathan B said:

1. If the BSL is not proper, is it not possible to communicate to MSP430 via JTAG using the FET?

2. If the BSL is programmed wrongly or if it is corrupted, is there is way to recover the same?

It depends on what is wrong. There are a couple of things that could cause you to not be able to access via JTAG after programming the BSL in:

1. There are 2 words located at the end of BSL memory that can be used to lock the JTAG access - this is the addresses 0x17FC-FF. If the value there is anything except for 0xFFFFFFFF or 0x00000000, then JTAG access is locked and you won't be able to get in via JTAG. However, if there is a "good" BSL present, you should still be able to access the part that way.

Looking at the txt file you attached I see FFFF at 0x17FC-FF so this should be ok.

2. Could be some timing issue with the running of the BSL protect function that always runs at startup.

Using CCSv5.5 I tried to reproduce your error.

First I loaded the BSL example project. After this, if I didn't power cycle the part or anything but immediately tried to load my blinking LED project, it worked fine. If I power cycled the part however, then tried to load a blink the LED project, I got an error (but different from yours): mine said the load failed because it could not erase at 0x5c00.

So next I tried using Elprotronic FET Pro430 Lite software, and I was able to successfully load the blinking code. So to me, this sounds like perhaps a timing issue or an issue in the DLL, since the Elprotronic version I have has a newer FET tool firmware version than CCSv5.5.

You may want to try seeing if you can access the part using other software and see if you can get back in.

Finally, I decided to see if going to CCSv6 would fix your problem - so I repeated my test above all in CCSv6 - when I did this I had no problem getting into the part after loading the BSL, even if I had power cycled the part in between.

So if I were you, I'd try getting in with the Elprotronic software, and I'd ultimately install the latest CCSv6 as well.

Hope this helps, and best of luck.

Regards,

Katie

Hi Katie,

Thank you so much for your inputs. Now I am able to flash the example BSL code into the flash successfully.

But I am stuck with another issue. I have modified the below line in BSL430_Low_Level_Init.asm:

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

The above line has been modified to check the I/O pin (P2.6) connected to Switch (in experimenter board) for making the BSL entry. Now I am getting the following error:

"../lnk_msp430f5438a.cmd", line 114: error: program will not fit into available
   memory.  placement with alignment fails for section "ZAREA_CODE" size 0x44 .

   Available memory ranges:
>> Compilation failure
   ZAREA_CODE   size: 0x2e         unused: 0x2e         max hole: 0x2e
error: errors encountered during linking; "BSL.out" not built

The code does not fit in the ZAREA section. Kindly help to proceed further on the above issue.

Regards,

Ranganathan

Hi Ranganathan,

The section ZAREA_CODE is only defined in this custom linker to be 0x2e bytes, and when I build I can see in the map file that this is exactly the size of the code placed there. Your code for this section is of size 0x44 after you implemented your changes, so it doesn't fit. You'll need to modify your linker file to have room for this - but it will mean taking some of the area that is currently set aside for the rest of the BSL code, so you'll have to hope it all still fits. You can also see if there's anything you can do to optimize the way you've written your GPIO check.

1. For modifying the linker file, first, make a copy of the original linker file and save it somewhere or give it a different name so that it's easy to undo your changes if you need to - you can always revert to this file.
2. You'll want to look at the length listed for ZAREA_CODE in your error message, and adjust the ZAREA_CODE length in the linker file to match.
3. Then you will need to see what address your new length places the end of ZAREA_CODE when you add the length to its start address, and see how it conflicts with the FLASH section right below it in the linker. Adjust the FLASH start address to match this now.
4. Then adjust the FLASH length so that the end of the FLASH section does not go beyond where it did before, since you can't change where the end of BSL memory is - that is fixed.

Now you'll have to hope it all still fits when you build (the BSL area is only 2k so it can be tight sometimes, depending on the complexity of your BSL). Essentially what this does is take area assigned to FLASH section for your main BSL code, and gives it to the ZAREA_CODE section instead, where the BSL Protect etc that run before BSL entry are located.

Please be sure to note one other thing, since you are altering the BSL_Protect function of the BSL: see section 1.2.1 of www.ti.com/lit/pdf/slaa450 "The BSL Protect function is a function that is called after each BOR and before user code is executed. There is no time and functionality limit placed on this code; however, if this function does not return, it renders the device totally unresponsive. Additionally, excessively long delays in the return functions could lead to problems during debug."

Regards,

Katie

Hi Katie,

I modified the ZAREA size in linker file to solve this issue. I have increased ZAREA code to 0x50 and reduced the flash area size.

Regards,
Ranganathan

Hi Katie,

Thank you so much for your inputs. I am able to take control of the BSL and also communicate with the BSL through UART. I have tried couple of commands like BSl Version,  Buffer size and mass erase. Its working good.

But my intention is to upgrade the application code in the flash via Rx Data block command. I have following doubts regarding the same:

1. I am compiling the application using CCS. Which output file i should use for the upgrade through BSL?

2. How to identify the code and data sections from the output file and the corresponding addresses so that these addresses can be sent in the address fields of the command?

Please help on the above things so that i can proceed further.

Thanks and Regards,

Ranaganathan

Hi Ranganathan,

I'm glad to hear that things are working for you!

Ranganathan B said:

1. I am compiling the application using CCS. Which output file i should use for the upgrade through BSL?

You will want to refer to this wiki page: http://processors.wiki.ti.com/index.php/Generating_and_Loading_MSP430_Binary_Files#Using_CCS_v6.x (on the same page there are also instructions for CCSv5 and IAR). Simply take the project for your main application code that you are wanting to load, and follow those steps - you should end up with a TI-txt or hex file in the Debug folder of the project, which you can then use to load the firmware via BSL.

I'm not sure what you are using as the host for your BSL - if you use for example our BSL Scripter software that comes included with www.ti.com/lit/zip/slau319 www.ti.com/lit/pdf/slau319 , the BSL Scripter software uses a TI-txt format file so that is what you would want to generate in CCS.

Ranganathan B said:

2. How to identify the code and data sections from the output file and the corresponding addresses so that these addresses can be sent in the address fields of the command?

In a TI-txt format file, the format is like this:

@4400

aa bb cc dd

Where this would mean at address 0x4400 you will find two words, 0xBBAA 0xDDCC, or if you are looking at it byte-wise, 0xAA 0xBB 0xCC 0xDD. It is a very straightforward format in this way. I think a good way to understand the TI-txt format is to look at the TI-txt file, but also program the code in via JTAG and look at the same addresses using the memory window - this will help you see how the TI-txt file corresponds to what gets written into memory.

If you are trying to write your own custom BSL host instead and want to know how to handle sending a code file into the part (breaking it into blocks etc), you can look at the source code for the BSL scripter - the source is included in the download www.ti.com/lit/zip/slau319

Regards,

Katie

Hi All,

Last time Lois and Katie helped me greatly with the bootloader issue. Now we have finaly got time to implement the bootloader in our main project. The firmware is downloaded via bluetooth in memory banks C and D (we are using the MSP430F5438A). 

Using the dual image method we have defined our app space in bank A and B, the firmware is to big for one memory bank. We have changed the .cmd file to define the spaces. When we compile the bootloader project we get some warinings that all have to do with higher memory problems where the address is greater then 16 memory pointer.

Like below

relocation from function "main_boot" to symbol "_App_Reset_Vector" overflowed; the 17-bit relocated address 0x17bfe is too large to encode in the 16-bit field (type = 'R_MSP430X_ABS16' (15), file = "./main.obj", offset = 0x00000016, section = ".text:main_boot") main.c /BootloaderMSP430F4538A line 623 C/C++ Problem

The bootloader also does not run, the bootarea is defined in the range of  FC00-1FFFF. This means we cannot start the bootloader. A solution is (we think) is using the large data model, but we can't use this because we use Bluetopia that has been compiled using the small data model and is therefore not compatible with a large data model project. 

Does anybody have a suggestion or tip how to solve this problem? And is this the actual problem why the bootloader does not start. When starting the program with the debugger we get "no sources avaliable at 0xfe38"

Any feedback is welcome! If more information is needed (or code) please let us know!

Below is the .cmd file that we use with the bootloader project (for Louis: this is the same file that you modifed for us, we changed the app, download and boot spaces):

UPDATE:

Made a new post with this question because technically this is not a BSL but bootloader with dual image question.

/******************************************************************************/
/* LINKER COMMAND FILE FOR MSPBoot BOOTLOADER USING MSP430F5438A */
/* File generated with MSPBootLinkerGen.pl on 05-05-2014 */
/*----------------------------------------------------------------------------*/

/****************************************************************************/
/* SPECIFY THE SYSTEM MEMORY MAP */
/****************************************************************************/
/* The following definitions can be changed to customize the memory map for a different device
* or other adjustments
* Note that the changes should match the definitions used in MEMORY and SECTIONS
*
*/
/* RAM Memory Addresses */
__RAM_Start = 0x1C00; /* RAM Start */
__RAM_End = 0x5BFF; /* RAM End */
/* RAM shared between App and Bootloader, must be reserved */
PassWd = 0x1C00; /* Password sent by App to force boot mode */
StatCtrl = 0x1C02; /* Status and Control byte used by Comm */
CI_State_Machine = 0x1C03; /* State machine variable used by Comm */
CI_Callback_ptr = 0x1C04; /* Pointer to Comm callback structure */
/* Unreserved RAM used for Bootloader or App purposes */
_NonReserved_RAM_Start = 0x1C06; /* Non-reserved RAM */

/* Flash memory addresses */
/* Download area: 20000-3FFFF*/
/* App area : 5C00-17BFF*/ /* LR: Modified to have same area for download and boot*/
/* Boot area : 1FC00-1FFFF*/ //3ff
_FLASHDOWN_START = 0x5C00; /* Start if download area */
//_FLASHDOWN_START = 0x10000;
__Flash_Start = 0x5C00; /* Start of Flash */
__Flash_End = 0x17BFF; /* End of Flash */
/* Reserved Flash locations for Bootloader Area */
__Boot_Start = 0x1FC00; /* Boot flash */
__Boot_Reset = 0x1FFFE; /* Boot reset vector */
__Boot_VectorTable = 0x1FFD0; /* Boot vector table */
__Boot_SharedCallbacks_Len = 4; /* Length of shared callbacks (2 calls =4B(msp430) or 8B(msp430x) */
__Boot_SharedCallbacks = 0x1FFDC; /* Start of Shared callbacks */
/* Reserved Flash locations for Application Area */
_AppChecksum = (__Flash_Start); /* CRC16 of Application */ /*LR: Not used for now */
_AppChecksum_8 = (__Flash_Start+2); /* CRC8 of Application */ /*LR: Not used for now */
_App_Start = (__Flash_Start); /* Application Area */
_App_End = (0x17BFF); /* End of application area (before boot) */ /* LR: modified to show the real usage */
_CRC_Size = (_App_End - _App_Start +1); /* Number of bytes calculated for CRC */ /*LR: Not used for now */
_App_Reset_Vector = 0x17BFE; /* Address of Application reset vector */ /* LR: modified to show the real usage */
_App_Proxy_Vector_Start = 0x17A00; /* Proxy interrupt table */ /* LR: Application doesn't have proxy table, so interrupts won't work */
// Addresses for Dual Image support in download ares
_AppChecksumDown = 0x1800; /*LR: Not used for now */
_AppChecksumDown_8 = (_FLASHDOWN_START+2); /*LR: Not used for now */
_App_StartDown = (_FLASHDOWN_START); /* LR: modified to show the real usage */
_App_EndDown = (__Flash_Start-1); /*LR: This is OK */

/* MEMORY definition, adjust based on definitions above */
MEMORY
{
SFR : origin = 0x0000, length = 0x0010
PERIPHERALS_8BIT : origin = 0x0010, length = 0x00F0
PERIPHERALS_16BIT : origin = 0x0100, length = 0x0100
// RAM from _NonReserved_RAM_Start - __RAM_End
RAM : origin = 0x1C06, length = 0x3FFA
INFOBOOT : origin = 0x1800, length = 0x200
// Flash from __Boot_Start -( __Boot_SharedCallbacks or INT_VECTOR_TABLE)
FLASH : origin = 0x1FC00, length = 0x2DC
// Shared callbacks from __Boot_SharedCallbacks + Len (when used)
BOOT_SHARED_CALLBACKS : origin = 0x1FFCC, length = 4

// Boot vector Table from __Boot_VectorTable- __Boot_Reset
INT_VECTOR_TABLE : origin = 0x1FFD0, length = 46 // 46 means 23 vectors
// Boot reset from __Boot_Reset-__Flash_End
RESET : origin = 0x1FFFE, length = 0x0002

//INT42 : origin = 0xFFD4, 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 */

.text : {} >> FLASH |INFOBOOT /* CODE */
.cinit : {} >> FLASH |INFOBOOT /* INITIALIZATION TABLES*/
.const : {} >> FLASH |INFOBOOT /* CONSTANT DATA */
.cio : {} > RAM /* C I/O BUFFER */

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

.BOOT_APP_VECTORS : {} > BOOT_SHARED_CALLBACKS
/* MSP430 INTERRUPT VECTORS */
.BOOT_VECTOR_TABLE : {} > INT_VECTOR_TABLE
.reset : {} > RESET /* MSP430 RESET VECTOR */
}

/****************************************************************************/
/* INCLUDE PERIPHERALS MEMORY MAP */
/****************************************************************************/

-l MSP430F5438A.cmd

Hi,

I am working on firmware update over bluetooth.

I am using CC2564 with Bluetopia interfaced to MSP430BT5190.

My application needs bluetooth.

I want to use the same bluetooth for both APPLICATION and FIRMWARE UPDATE i.e) in the normal mode bluetooth should work with APPLICATION to transfer the data AND in FIRMWARE UPDATE mode it has to receive new firmware from smartphone and rewrite the APPLICATION code, is it possible?

and is it possible for my set up (BT5190-CC2564) ?

Thanks 

Arun

Hello Roy,

I have to use large data model. Do you have code available?

Regards,

Deep

Hi Roy,

I am using MSP430FR5969 (FRAM: 0x4400-0x13FFF) and CCS 6.0 for our development.

For me also the requirement is to upgrade the FW on wireless. My idea is to receive new FW image in the existing application and write it in the download area, then call MSPBoot. Our application size initially we decided around 22KB, below is the memory map

/* Download area: 4800-9FFF*/
/* App area     : A000-F7FF*/
/* Boot area    : F800-FFFF*/

this was to avoid large data model.

But now it seems that our application size will grow more than 22 (probably: ~28 KB) and this puts us into the situation to mandatory use the large data model.

1. What I thought in this case to divide the download area in two parts (with same memory map as above), second part will be in large data model (0x10000 - 0x13FFF). To read and write I can use "__data20_write_char(longAddress, byte), __data20_read_char (longAddress)" intrinsic functions. In this case, I need help to create the linker file to separate Download area in two parts.

2. The second idea would be to shift the MSPBoot inside large data model (0x10000 - 0x13FFF) but in this case also, download area has to be partitioned in two parts. Again I need help to create the linker file to separate Download area in two parts (one in large data model and second in 0x4400-0xFFFF) + MSPBoot for large data model. This looks the best solution to me as both App and Download area will be in contiguous memory but in this case special handling (protection) of 'interrupt vectors and signatures' will be required.

OR do you have some other idea.

Hope this gives you a fair idea about my requirement.

Regards,

Deep

Hi,

1. Do you have large data model bluetopia stack? If not and you want to use large data model then you need to get it (if your application code is (partly) in the extended memory. 

2. In both cases the download area is jus seen as one space in the memory right? E.g. when starting from 0x9500 and ending at 0x12000 do you see this as one space?

3. Incase of youre second option you definitly will need large data model and you need to adjust your interrupt vector, this is called vector rederection. Note that the orgional MSP vector addresses cannot be changed.  For this see SLAU600(a).

4. Also you in the second case and maybe in the first case you need to make mspboot compatible with large data model.

5. For youre first option, if you are 100% that the application space will remain in the lower memory then you can just adjust the linker file. See MSPBoot for a example how to customize the linker file.

If you have any more questions let me know.

With kind regards,

Roy