• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 80 subscribers
  • Views 142 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.

MSP430FR5994: In-system Firmware Upgrade fails if .text:_isr section moves

Bryan Evenson24
Intellectual 540 points
Part Number: MSP430FR5994

I have a TI-RTOS based project that is capable of in-system firmware upgrade.  Firmware upgrade operates as follows:

  1. Erase the upper half of FRAM
  2. Download the new firmware into the upper half of FRAM
  3. Authenticate the new firmware
  4. Run the firmware upgrade function from RAM
    1. Note in information memory that firmware upgrade is occurring
    2. Erase the bottom half of FRAM
    3. Copy the upper half of FRAM into the bottom half of FRAM
    4. Restart with the following code:
    5. PMMCTL0_H = PMMPW_H;
PMMCTL0_L |= SVSHE_1 | PMMSWPOR | PMMREGOFF;
__bis_SR_register(LPM4_bits | GIE);

This has worked well for me in the past, but I had problems with my latest firmware change.  I've been storing data in INFOA to track progress during and after firmware upgrade to confirm what is happening.  I've determined that if the .text:_isr section moves (still in FRAM and near its old location), then the MSP430 locks up and does not even reach main() after the POR triggered at the end of firmware upgrade.  When this happens, I need to enact a hard reset, after which the MSP430 is running the new firmware.  However, if the .text:_isr section does not move, then the POR works as expected and the MSP430 is immediately running the new firmware.

I am storing the reset vector (contents of 0xFFFE) just before copying over the new firmware and just after.  I have confirmed that 0xFFFE correctly points to the new reset vector location just before the POR at the end of firmware upgrade.  From my understanding, the MSP430 should then read the new reset vector address after the POR and start running the new code.  Is there anything else that I need to do if the .text:_isr section moves prior to forcing a POR so the MSP430 restarts properly?

  • 0
    Guru 18915 points

    So the reset vector is the only vector that gets updated? That would be big problem if you have any interrupt service routines and it looks like you do.

  • 0 in reply to David Schultz
    Intellectual 540 points

    David,

    I don't think I explained things correctly.  All the code, including the full ISR table, gets re-written with the new firmware.  Based on the standard linker command file, the .text:_isr section with the ISR table will be located wherever the linker sees fit in FRAM.  Additionally, I have been storing the reset vector contents before and after firmware upgrade in INFOA for debug purposes only.  When I do in-system firmware upgrade, the MSP430 locks up if the .text:_isr section moves to a different location because of the new firmware.  In my case, the .TI.persistent section changed in size and shifted the position of .text:_isr.  I am assuming that the reset vector is the only one that is a problem since I do not reach main() after the firmware upgrade until I enact an external hard reset.

    Has anyone else experienced anything similar, or know what else I could possibly check?

  • 0 in reply to Bryan Evenson24
    Guru 18915 points

    Another thing to worry about is your reset code. The block diagram in the user guide shows a delay from setting PMMSWPOR to POR. How much it doesn't say but it wouldn't take much.

    Presumably GIE has been cleared all through the code copying phase so there could be an  interrupt queued up and waiting. So when you set GIE, the ISR is called. The new ISR. Maybe nothing bad happens there.

    But if the ISR decides to exit the low power mode on exit, what does your code do then? I would skip enabling interrupts and just because I am that paranoid, put the low power mode entry code inside an infinite loop.

  • 0 in reply to David Schultz
    Intellectual 540 points

    David,

    I do disable the interrupts prior to firmware upgrade, so an interrupt that triggered during firmware upgrade could be a concern.  The last line puts the device in LPM3.5.  This is what I do for my normal sleep mode shutdown and this is what I had been using as my safeguard against the firmware upgrade function exiting.  It should immediately enter LPM3.5, but then it may immediately wake up if there was an active interrupt.

    However, I tested adding an infinite loop immediately after the POR request.  I'm still exhibiting the same problem.  The device restarts properly if the .text:_isr section doesn't move, but it locks up if this section does move with the firmware upgrade.

**Attention** This is a public forum