• State
  • Replies 3 replies
  • Subscribers 21 subscribers
  • Views 105 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MSP430F5437A: Bootloader understanding

swanand zanpure
Prodigy 30 points

Part Number: MSP430F5437A
Other Parts Discussed in Thread: MSP430F5437

Hello Team,

We have reviewed the bootloader documentation and related forum discussions.From the documentation and examples (including MSPBoot), our understanding is as follows:1. The MSP430F5437A does not support hardware flash bank swapping.
2. Therefore, the firmware update mechanism uses a "Download Area" in flash as a temporary buffer to store the incoming application image.
3. After the complete image is received and validated (CRC/integrity check), the bootloader copies the image from the "Download Area" to the "Application Area", which is used for execution.Based on this, it appears that the upgrade process relies on a "Download Area → Validation → Copy to Application Area" flow, rather than a "dual-application (App1/App2) swappable-bank approach".Could you please confirm if this understanding is correct for the MSP430F5437A architecture?Additionally, we would appreciate clarification on the following points:1. Is the Download Area buffering method the recommended approach for this device family?
2. Are there any TI reference implementations supporting a dual-application (2N) firmware update strategy for MSP430F5xx devices? 

Best Regards,

Swanand

  • 0
    TI__Genius 11685 points

    Hi Swanand,

    MSP430F5437 does not support hardware bans swap. What you descript is correct and also is mentioned in MSPBoot – Main Memory Bootloader for MSP430 Microcontrollers (Rev. E). And this is our current solution for Dual Image requirement during bootloader, to make sure there is always a valid image existing in memory in case of bootloader process is interrupted unexpectedly. 

  • 0
    Prodigy 30 points

    Hello Pengfei_xie,

     

    Thank you for confirming the firmware upgrade approach for the MSP430F5437A using the Download Area → Validation → Copy to Application flow as described in MSPBoot.

     

    We have a follow-up question regarding the system architecture.

     

    In our design, we are considering moving the firmware download logic from the bootloader to the main application. The intention is to keep the bootloader minimal and handle all communication and firmware transfer in the application layer.

     

    The proposed flow is as follows:

     

    1. The running application receives the firmware upgrade package through the communication interface.
    2. The application stores the incoming firmware image into a reserved Download Area in flash.
    3. After the download is completed, the application performs basic validation (e.g., CRC check).
    4. The application sets an upgrade flag in a reserved flash location and triggers a system reset.
    5. After reset, the bootloader checks the upgrade flag. If set, it copies the image from the Download Area to the Application Area and then jumps to the updated application.

     

    We would like to confirm the following:

     

    1. Is this architecture recommended or acceptable for the MSP430F5437A device?
    2. Are there any constraints or precautions when writing to the Download Area from the application while the application itself is executing from flash?
    3. Does TI provide any reference implementations where the firmware download is handled in the application and the bootloader is used only for the image installation step?

     

    Any guidance or recommendations would be greatly appreciated.

  • 0 in reply to swanand zanpure
    TI__Genius 11685 points

    Hi Swanand,

    swanand zanpure said:
    1. Is this architecture recommended or acceptable for the MSP430F5437A device?

    The firmware update process looks fine from my side. Just one comment: The upgrade flag should be cleared after the firmware is copied from Download Area to Application Area, to make  sure the boot process without firmware update could directly jump to Application Area.

    swanand zanpure said:
    2. Are there any constraints or precautions when writing to the Download Area from the application while the application itself is executing from flash?

    The MSP430F5437A has multi physical flash banks, so the application program could be executed while the erase/write operation is ongoing in another flash bank. So you just need to make sure the Download Area and Application Area are located in different flash banks. You could see 9.4 of MSP430F543xA, MSP430F541xA Mixed-Signal Microcontrollers datasheet (Rev. H) for flash bank information.

    swanand zanpure said:
    3. Does TI provide any reference implementations where the firmware download is handled in the application and the bootloader is used only for the image installation step?

    As for flash operation for this device, you could refer the example code in msp430x54xA_flashwrite_01.c