MSP430F5358: Issue in using Main Memory based Bootloader using MSPBoot Templates

Hi Ashish,

Do you mean the data located at 0x8002~0x8006 will be changed to 0xFF?

Hello Gary,

Data from 0x8000 to 0x8003 is changing to FF

Ashish

Hi Ashish,

First 0x8000~0x8001 is used for application's CRC value that is calculated and write by host device. The application code is start from 0x8002 and when I build the projects you provided above it has the data of 0x8100 at address 0x8002~8003 as below

I think there some thing wrong with your host side.

Best regards

Gary

You mean the script that send the data?

I have verified that the downloaded data is correct after transfer completion from host. Also have verified that the CRC was validated and bootloader code did copy the data properly to required location. But after reset the data was corrupted.

Ashish Mishra said:

You mean the script that send the data?

No, for the demo in SLAA600d is using a host MCU to handle this as below.

Ashish Mishra said:

I have verified that the downloaded data is correct after transfer completion from host.

The download area is 385FC-67FF7, please make sure that.

Ashish Mishra said:

bootloader code did copy the data properly to required location

The actual application area is located at 8000-F3FF & 10000-385FB (First two bytes are CRC value), could you help to capture the data when this finished?

Ashish Mishra said:

But after reset the data was corrupted

How do you do the reset?

I am curious that the sector size is 512 bytes, if a erase happen, it should erase 8000~8200.

Gary Gao said:

No, for the demo in SLAA600d is using a host MCU to handle this as below.

So basically we are sending data using PC com port to Main Memory boot. We have some C code which emulates the command to send the data.

Gary Gao said:

The download area is 385FC-67FF7, please make sure that.

Yes, we are making sure that the transferred data goes to this location only.

Gary Gao said:

The actual application area is located at 8000-F3FF & 10000-385FB (First two bytes are CRC value), could you help to capture the data when this finished?

I will try to get the dump when the data is copied from download area to main application area.

Gary Gao said:

How do you do the reset?

Main Memory bootloader has the code to reset the controller once it has validated the downloaded binary and copied it to application area.

#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

Thanks

Ashish

When you finished the application update, when reset the device it will check if Application reset vector exists as below

And then it will start the application code. So don't know there get the erase event happen.

Update:

Just checked and realized that, when the download completes and bootloader validate the CRC, it issue the erase command for app area. There its erasing first four byte from location 0x385FC to 0x385FF.

Working on to relocate the region so that it does not fall in some segment boundary.

I have modified the linker file for bootloader. Now the erase is not happening. But now problem is, even though everything is ok, its still not jumping to app. If i manually rerun the bootloader, following piece of code is failing

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

Basically Hardware entry condition in order to force bootloader mode is getting set, due to which its always staying in bootloader.

HW_ENTRY_CONDITION      (!(P1IN & BIT1))

Ashish Mishra said:

I have modified the linker file for bootloader.

How do you make the modify? 

You can add a GPIO toggle event to show if the function  TI_MSPBoot_APPMGR_JUMPTOAPP() have been executed.

Gary Gao said:

How do you make the modify? 

Since the address 0x395FC--0x395FF were falling in the same segment as of app area's last segment during erase, we modified the download area to start from 0x39600 and accordingly reduced the size of main application. This way, i was able to avoid the erasure.

Gary Gao said:

You can add a GPIO toggle event to show if the function  TI_MSPBoot_APPMGR_JUMPTOAPP() have been executed.

Our application is toggling a GPIO once the application is loaded.

Ashish Mishra said:

You can add a GPIO toggle event to show if the function  TI_MSPBoot_APPMGR_JUMPTOAPP() have been executed.

Our application is toggling a GPIO once the application is loaded.

GPIO toggle event in application is not the case I want to check. I want to check if TI_MSPBoot_APPMGR_JUMPTOAPP() have been executed. You can put a GPIO toggle event before this function.

 I recommend to modify the application area as below

/* App area : 8000-F3FF & 10000-38400*/
/* Download area: 385FC-67FF7*/
/* Boot area : F400-FFFF*/

Please modify boot and application project CMD at both time.