• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 77 subscribers
  • Views 579 views
  • Users 0 members are here
Support feedback
Options
Options

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Ashish Mishra
Intellectual 370 points
Part Number: MSP430F5358

Hello Team,

We are trying to develop Main Memory Bootloader for our controller to be programmed in field by using UART(without FET). For this purpose, we followed the procedure defined in SLAA600d. We downloaded the MSPBoot templates, created boot and application project as per the document for DUAL image UART mode 20 Bit.

I was able to  send the the image to controller using UART, and could see it got downloaded in the memory, CRC validated, copied the downloaded image to main application area. But once controller reboots, application does not run. For this we checked the main application area and could see that 1st 4 bytes are erased/overwritten with 0xFF.

We are not able to figure out why the first 4 bytes are being overwritten.

XT2 32 MHz, MCLK=ACLK=16MHz, SMCLK = 8MHz, UART = USCI1, Baud = 115200.

For reference attaching the boot and application project.

Thanks

Ashish

MSPBoot_Project.zip

  • 0
    TI__Mastermind 38665 points

    Hi Ashish,

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

  • 0 in reply to Gary Gao
    Intellectual 370 points

    Hello Gary,

    Data from 0x8000 to 0x8003 is changing to FF

    Ashish

  • 0 in reply to Ashish Mishra
    TI__Mastermind 38665 points

    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

  • 0 in reply to Gary Gao
    Intellectual 370 points

    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.

  • 0 in reply to Ashish Mishra
    TI__Mastermind 38665 points
    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.

  • 0 in reply to Gary Gao
    Intellectual 370 points
    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

  • 0 in reply to Ashish Mishra
    TI__Mastermind 38665 points

    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.

  • 0 in reply to Gary Gao
    Intellectual 370 points

    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.

  • 0 in reply to Ashish Mishra
    Intellectual 370 points

    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))

  • 0 in reply to Ashish Mishra
    TI__Mastermind 38665 points
    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.

  • 0 in reply to Gary Gao
    Intellectual 370 points
    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.

  • 0 in reply to Ashish Mishra
    TI__Mastermind 38665 points
    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.

  • +1 in reply to Gary Gao
    Intellectual 370 points

    Hello Gary,

    I was able to get rid of forced boot that was coming due to HARDWARE entry pin. The pin was always getting set in hardware due to which it was forcing the boot. After changing the HARDWARE entry pin to other free GPIO it worked.

    Gary Gao said:

    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.

    I will try to use the setting that you have suggested.

    Thanks

    Ashish

**Attention** This is a public forum