• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 245 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.

MSP430FR2633: The program does not work when the boot is refreshed

Yale Li 李耀先
Expert 4660 points
Part Number: MSP430FR2633

Hi Team,

Here’s an issue from the customer may need your help:

Customers use custom BootLoader. There is a problem with the boot program and needs to be modified. But the product is sealed, so they need to use the app to flash the boot program.

The original boot and app cmd files are as follows:

The instruction that boot jumps to app: asm(" mov &0xEDFE, PC;");

Since the new boot program is larger than the original, the app cannot be used to refresh the boot directly, so two apps are designed: app1 and app2. app1 is mainly used as a transit. The program jumps from the original boot to app1, app1 redirects the interrupt vector, and then jumps to app2; app2 receives the data and stores it in the memory (the memory space is the original boot+app1). The relevant cmd files are as follows:

A to B: success

B to C: APP2 receives and stores data. When it is stored to 0xF400, the program does not work (they use printing debugging information to monitor the program when updating the boot, and find that the program cannot run after the program receives the boot program data. It also cannot run after power off and restart).

They guessed that it might be due to the INT area. When the app refreshes the boot, the interrupt is used. It may be because the INT interrupt vector of app1 is rewritten when the app is refreshed, and the interrupt cannot be found and it does not work.

Thanks & Regards,

Yale Li

  • 0
    TI__Genius 10060 points

    Hi Yale,

    I'm not sure I understand the customers approach. Please correct my assumptions below:

    • Customer needs to increase the size of boot
    • APP1 is designed to jump to APP2 immediately
    • APP2 is a special one-time bootloader that will updated the system custom 'boot' bootloader

    Is this correct?

    Also, what is the customer strategy for redirecting the interrupts? I didn't understand the code you posted above.

    Please note that SYSRIVECT can be used to change the location of the interrupt table:

    Why doesn't the customer use BSL? If the customer believes they cannot use BSL then they can still look at BSL source code as an example for bootloader operation. 

    See https://www.ti.com/tool/MSPBSL

    Does the customer have a non-seal device to experiment on? It would be ideal, so they avoid locking the sealed device?

    Regards,

    Evan

  • 0 in reply to Evan Lew
    TI__Expert 4660 points

    Hi Evan,

    It's correct.

    And I know why he designed like this now:

    Because he wants to update the boot, not using boot to update app.

    And please pay attention to this instruction on his original boot:

    Yale Li 李耀先 said:
    asm(" mov &0xEDFE, PC;");

    Thanks & Regards 

    Yale Li

  • +1 in reply to Yale Li 李耀先
    TI__Genius 10060 points

    Hi Yale,

    If the customers app and/or boot are using interrupts they cannot rely on "INT (APP1)" 0xF400-0xF300 to forward IRQs because at somepoint the new boot code will overwrite it, right?

    I would recommend update the interrupt table to point directly at the new ISR (at 0xEDFE) or to use SYSRIVECT instead.

    Hope that helps. Let me know if you have more questions.

    Regards,

    Evan

  • 0 in reply to Evan Lew
    TI__Expert 4660 points

    Hi Evan,

    Thanks for your follow up support. And sorry for this late confirmation.

    Thanks & Regards

    Yale Li

**Attention** This is a public forum