• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 210 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.

MSPM0G1519: _WFI() in ISR

Munan Xu
Expert 5330 points
Part Number: MSPM0G1519


Tool/software:

Hello,

I have a customer migrating code from an STM32 MCU and one of the things they have in their systick ISR is a _WFI() so that they can pause the execution state within the isr and do something on the next systick.

They noticed on MSPM0 this doesn't seem to work. I created a small proof of concept with our systick example and it seems that this doesn't work:

I assume this type of interrupt is not allowed on MSPM0 and CPU subsystem since technically you are still in an interrupt context?

Munan

  • 0
    Guru 101335 points

    The NVIC is specified such that an ISR won't pre-empt itself. ARMv6-M Architecture Reference Manual (DDI0419E) Sec B1.5.19 says "WFI wake up events: [...] An asynchronous exception at a priority that, if PRIMASK.PM was set to 0, would preempt any currently active exceptions." [emphasis added]

    The v7 and v8 ARM-s have similar verbiage. As far as I know, the STM32-s don't do this differently.

    SysTick is typically given a very low priority, so almost any other interrupt will pre-empt it. I wonder if this is actually waiting for something else (intentionally or not).

  • +1 in reply to Bruce McKenney
    TI__Expert 3760 points

    Hi Munan,

    To continue from what  has said: Until the current IRQ handler is exited, it is considered active, and won't be jumped to again until it is complete. You can jump to other higher priority ISR's, but not that same one. 

    Best Regards,
    Brian Lee

  • 0 in reply to Brian Lee
    Guru 101335 points

    The other path would be a resumption from the WFI (without calling an ISR), but the quote from the Armv6-M ARM says that won't happen either.

    Would posting the original code be informative?

  • 0 in reply to Bruce McKenney
    TI__Expert 5330 points

    Hey Bruce, Brian,

    Appreciate the feedback here, I think in discussing with the customer they agree that trying to nest interrupts like this isn't a reliable solution. They'll move on with a more traditional switch statement or variable to keep track of state in the ISR instead.

    I think what you're saying about interrupt priority makes sense, it seemed like the behavior was that occasionally the code would immediately resume or it would stay stuck depending on what other interrupts were enabled.

    Munan