• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 78 subscribers
  • Views 270 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

MSP430FR6989: Firmware update handled by firmware (without bootloader)

MSP430FR6989: Firmware update in application (not in bootloader)

Wui Fan Lim
Prodigy 30 points
Part Number: MSP430FR6989

Hi,

I am reposting this as a continuation of my previous post MSP430FR6989: Firmware update handled by firmware (without bootloader).

I am trying to find a way to achieve firmware update that is handled in the application itself (without entering bootloader state). My idea is that I can have a function in my firmware that handles the firmware validation and writing into memory address. Let's call this function as "in-app bootloader". To achieve this, "in-app bootloader" must be functional and not to be overwritten during firmware update. Is there any way to achieve this? Or more specifically, how to define in the linker file (I suppose this is the area to edit) to exclude or to prevent the memory address of the "in-app bootloader" from being overwritten, while the "in-app bootloader" remains as a part of the complete firmware image?

I can't find much forum posts that discuss about this. Would really appreciate if anyone could also share with me if you find any forum post to be relevant.

I would also like to answer the question to me from the previous post (I am sorry that I didn't reply to the question quickly as I was dragged by other projects):

"Are you talking about something like a main memory bootloader (take a look at MSPBoot (https://www.ti.com/lit/slaa600) for an example).

Or something more in main application rather than abstracted into a separate bootloader and application? You do have to be careful when writing to the same memory you are running from."

My answer is no. In fact, I am currently using crypto-bootloader as my main memory bootloader now, and I now need to work on firmware-update-over-the-air (FOTA) which is not supported by my current bootloader. However, my device has been sealed up, so I no longer have access to the debug port (JTAG/SPW port), resulted that I am unable to access to and edit the bootloader. Therefore, I am trying to find a way to design an "in-app bootloader" that acts just like the main memory bootloader, but in the application level. Please advise if this is possible?

Thank you.

  • 0
    TI__Mastermind 18915 points

    Hi Wui,

    If you means FOTA, actually that FR6989 do not have any wireless interface. And if you want to access the device without JTAG/SBW, BSL can meet your requirement.

    Wui Fan Lim said:
    However, my device has been sealed up, so I no longer have access to the debug port (JTAG/SPW port), resulted that I am unable to access to and edit the bootloader.

    If no JTAG/SBW prot accessible, but default bsl interface is available. Ans both not work, it seems no other interface for the device to access.

    Wui Fan Lim said:
    I am trying to find a way to design an "in-app bootloader" that acts just like the main memory bootloader, but in the application level

    I think it can work. You can check the user's guide and finish the whole processing logic.Just like what the Crypto-Bootloader or ROM-Bootloader achieved.

    Wui Fan Lim said:
    r more specifically, how to define in the linker file (I suppose this is the area to edit) to exclude or to prevent the memory address of the "in-app bootloader" from being overwritten, while the "in-app bootloader" remains as a part of the complete firmware image?

    I think you can refer to the user's guide:https://www.ti.com/lit/ug/slau657/slau657.pdf 

    B.R.

    Sal

  • 0 in reply to Sal Ye
    Prodigy 30 points

    Hi Sal,

    Thanks for the info provided. I'll need to try them out first.

    Best Regards,

    Wui Fan

**Attention** This is a public forum