• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 653 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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:

LP-MSPM0G3507: Linker script for application when secondary BSL is used

LP-MSPM0G3507: Secondary bootloader updating BCR application CRC check

Alan
Prodigy 155 points
Part Number: LP-MSPM0G3507
Other Parts Discussed in Thread: MSPM0G3507

I'd quite like to use the BCR facility to check that the application is correctly programmed, and it looks like I need to ensure that APPCRCSTART, APPCRCLENGTH and APPCRC are programmed correctly to do this.  However, if a bootloader updates the application then I expect it would need to update these values.  Is there an example of this happening in the SDK examples?  I would have expected that they would be in a region that is statically write protected in production devices - or must NONMAIN be left writable in order to use this capability?  I expect to need to use a version of SWD Security Level 1 - does this change what is available?

  • 0
    TI__Mastermind 25570 points

    Hi Alan,

    We do have a secondary BSL example in the SDK default path is below.

    C:\ti\mspm0_sdk_version\examples\nortos\LP_MSPM0G3507\bsl\secondary_bsl

    View non-main as a way to check CRC on static values that you won't be updating. If you want CRC on dynamic values I suggest adding that in your secondary BSL. If you do want to use non-main on dynamic values then, you would need to update the CRC values.

    Regards,
    Luke

  • 0 in reply to Luke Ledbetter
    Prodigy 155 points

    Thank you for the response.

    I had seen that example, but it does not appear to show the use of the BCR CRC check to verify the application image contents.  It does appear to allow a CRC to be calculated over the application image, but this must be performed under the host's instructions.  Or have I misunderstood?

    If I put the CRC check into the secondary bootloader as you suggest, then this will only run when the bootloader is entered.  Ideally I'd like to use the functionality of the BCR that will run every time the chip starts up before the application is executed.

    You've suggested that I can update the CRC values if I want to use the non-main CRC check on dynamic values - is there an example that demonstrates the best practice for this?  I assume that all of the BCR configuration data sector will need to be erased and reprogrammed in this case, which could leave the chip in an undesirable state if interrupted.

  • 0 in reply to Alan
    TI__Mastermind 25570 points

    Hi Alan,

    Your caveat is correct, that is why I don't recommend using NONMAIN as the CRC check for data updates. If you had an interruption while writing to the NONMAIN (like a POR) then you could run into issues. We don't have an example based around this because it isn't really the best practice to use NON-MAIN in that manner. Non-main is better utilized for static values.

    You can implement the CRC check in your bootloader application code which will be beneficial when updating the app code.

    Regards,
    Luke

  • 0 in reply to Luke Ledbetter
    Prodigy 155 points

    Luke

    If I had a case where I had a secondary BSL being used to update the main application firmware, what would happen if was interrupted mid-program (due to a POR, for instance)?  The application would not be correctly programmed (so wouldn't execute correctly) but there would be no signal to re-enter the secondary BSL - presumably the application entry would keep being attempted?  I'm considering an application where there is no spare GPIO to use to force entry to the secondary BSL, and want to be sure that there is no risk of being locked out.

    Is the answer that I need to create *another* bootloader that runs every time, before my application?  This would be distinct and separate from the secondary BSL which is configured from the BCR configuration, and would use the startup vector table at 0x0 (and would have to configure the application's vector table location)?  In this case, is the secondary BSL even any use to me?

  • +1 in reply to Alan
    TI__Mastermind 25570 points

    Hi Alan,

    One option is to have 2 separate sections in your flash and update one image at a time. If the image becomes corrupted you will still run off the good image. (This will require you to have enough room to have 2 versions of the application code).

    Other option is to check during your boot if the app code is correct, if not then request an update. Put this section of code in the beginning of flash so after boot it will run this section, then you can jump to your main application afterwards.

    We do have boot manager examples to help validate updates.

    We have a boot manager example in the SDK, default paths below

    Example Code - C:\ti\mspm0_sdk_x_xx_xx\examples\nortos\LP_MSPM0G3507\boot_manager

    Document - C:\ti\mspm0_sdk_x_xx_xx\docs\english\middleware\boot_manager

    Regards,
    Luke

  • 0 in reply to Luke Ledbetter
    Prodigy 155 points
    Luke Ledbetter said:
    Other option is to check during your boot if the app code is correct, if not then request an update. Put this section of code in the beginning of flash so after boot it will run this section, then you can jump to your main application afterwards.

    Indeed, I think that this is the answer.  Instead of using the built-in CRC check and secondary BSL to allow my application to be updated and verified on boot, I'm going to create a section of code at the start of flash that performs this function and then jumps to the main application.