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.

Alternative implementation of MSPBoot

Other Parts Discussed in Thread: MSP430FG477

Hello,

I am trying to use MSPBoot to implement a Bootloader for the MSP430FG477 that takes the image via SPI from an external flash, which the application previously receivend via Bluetooth.

I wonder whether it is feasible to change MSPBoot in the sense that the bootloader is just an autarkic function (residing at the end of the FLASH) of the main application, which overrides the beginning of the FLASH, where the main app resides.


Wouldn't this have the advantages of:

-being able to debug the application via CCS, since we basically just have a single program and not a separated program for the bootloader and the main app? When the bootloader is always started first I guess CCS cannot debug the application since it doesn't know the current cources.

-not having the problem of how to obtain the very first version of the application.

-having no need to communicate via external variables between the bootloader and the main app?

I am currently trying to implement that idea, but since I am new to writing bootloaders I am interested if my thoughts are correct and if there may be general reasons that prevent that idea from working (which could save me some time until I maybe stumble over that issue myselve).

Thank you for any comment!

Best,

Stefan

  • Hello Stefan,

    It is entirely possible to create a single debuggable project that incorporates both the bootloader and application code so that the MSP430 executes the application upon startup instead of waiting to receive a new image from the SPI/BLE interface. However it should be understood that this can only be accomplished during the initial programming of the device using a JTAG interface or native BSL . The purpose of MSPBoot is to create a small, flexible main memory bootloader that a user can customize for their own purposes and demonstrate the relationship between bootloader and application code. Whenever field updates are required the user will need to interface with the bootloader to update the app through a custom firmware image, therefore the bootloader itself cannot be updated at this time. External shared variables should be kept in place or else any updates to the application will not be able to communicate through the shared channels incorporated into the MSPBoot firmware.

    Regards,
    Ryan
  • The fact that the CPU is capable of Erasing and Writing to Flash makes if possible to include features in you code to modify itself -- deleting existing features that you no longer wish to have, adding new features that you desire, and altering the function of exiting features.

    This is not necessary a "boot" nor a "loader".

  • Hey Ryan,
    thank you for the fast reply! Now I am optimistic :)
    Best,
    Stefan

**Attention** This is a public forum