• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 590 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.

RM48L952: Interrupts while reflashing

Will Treharne
Intellectual 270 points
Part Number: RM48L952
Other Parts Discussed in Thread: UNIFLASH

Hello,

I am having problems handling interrupts while reflashing the flash bank containing the interrupt vectors.

We have a bootloader running in the first two sectors of flash bank 0 followed by our application in the remaining sectors. The application needs to use nested interrupts so we're using the IRQ dispatch mode, following the TI app note. The bootloader interrupt vectors all just branch to the vectors at the start of our application, as per another TI app note.

The bootloader runs all code needed during reprogramming from RAM and uses an RTI timer interrupt to service a TPS65381 watchdog at regular intervals. I've set the RTI timer to use FIQ as we're using dispatch mode IRQ for the application code. However, the bootloader crashes once the flash programming sequence starts as soon as the RTI interrupt is triggered.

If I understand correctly, this issue occurs because you can't execute code (including the interrupt vectors) from a flash bank while writing to it. In an attempt to work around this I have tried using the Parameter Overlay Module to redirect accesses to the interrupt vectors to a RAM copy. Unfortunately, this still crashes with a prefetch abort when the RTI interrupt is triggered after flash programming starts. If we disable the RTI timer and watchdog, the reprogramming completes successfully.

I'm not sure why I see this issue as (as far as I can tell) I'm not running anything from flash at the time. Is this a sensible approach to using interrupts in the bootloader or is there another better way?

Many thanks

  • 0
    TI__Guru 59540 points
    Hello Will,

    It is highly recommended to disable interrupts during reprogramming. This is how all of our programmers are setup including CCS and Uniflash so the flash programming operation isn't interrupted.

    With that said, it becomes challenging to service the Q&A watchdog during this time. To do so, it would be necessary to copy code that services it to execute from RAM as well as the programming algorithm. The problem would be how to manage the response windows and the timing given the variability of the flash programming operation as the device ages (if you need to accomodate the maximum programming and erase timings specified int he datasheet).

    There are two options to manage this task.

    1.) Brut force. This would be the tried and true cycle count method and strategic placement of WD messages. Given the size of the programming application a lack of interrupts, program execution timing should be relatively deterministic from a timing perspective.

    2.) Force the PMIC into diagnostic mode so you don't have to service the WD. This means that the MCU would have to force a reset of the TPS device. The easiest way to do this might be to create intentional WD violations to cause the WD_FAIL_CNT to exceed 7 while WD_RST_EN=1. This, of course, will also force a reset of the MCU so you would need to store information in either SRAM or data Flash to indicate the reason for the reset and bypass the TPS safety init during boot time (would need to disable DIAGNOSTIC MODE Timeout) and go directly to your bootloader instead of the application. Once programming is complete, clear the flag and force a SW reset to boot normally into the new application code.
  • 0 in reply to Chuck Davenport
    Intellectual 270 points
    Hi Chuck,

    Many thanks for the suggestions. I eventually managed to get option 2 above working well. Something that caught me out for a while was that PMIC registers hold their data across the reset and also the 21ms it takes the BIST to complete on entry to the diagnostic state. After allowing for the delay I was able to successfully disable the watchdog and hold it in the diagnostic state to prevent it resetting during reprogramming.

    Many thanks