• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 80 subscribers
  • Views 853 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.

MSP430F5510: MSP430F5xx software interrupt via DMA7?

Jan Brittenson
Intellectual 315 points
Part Number: MSP430F5510

I'm porting a tasking library over to MSP430 and am tossing around ideas for how to perform a task switch.  Task is in this context is a simplified thread.  Normally these only occur in an interrupt context:

1. Interrupt happens

2. Interrupt handler initiates a context switch (by for example waking a task), which results in a software interrupt.

3. The handler completes, and may wake other tasks before it gets there.  At the end, a software interrupt is still pending, and the pending task is the highest priority activated one.

4. The handler RETI's.  Now the pending software interrupt is entered immediately when interrupts are reenabled.

5. The SWI handler loads up the pending contexts and RETI's to it.

The critical part here is that in an interrupt context posting an SWI leaves it pending and not executing immediately.  And that if there is no context switch there is no additional overhead with regard to saving and loading state.  (On ARM Cortex-M this is trivial and there is even an interrupt tail chain optimization for it.)

From a non-interrupt context:

1. The running context saves its state, with an adjusted stored PC (pointing to step 4 below)

2. It sets the pending task and posts an SWI

3. The SWI handler loads up and returns via RETI to the other context

4. When this task becomes active again it continues executing here

Would this work, using DMA channel 7 for example, then:

set DMA7CTL = DMAIFG | DMAIE to post a pending software interrupt (all other bits including DMAEN set to zero).

In the DMA interrupt handler:

Recognize DMAIV == 0x10 as indicating an SWI and perform a context switch.

This would be the easiest.  But the documentation isn't clear whether setting IFG actually posts an interrupt...

Or is there an easier way to accomplish the same?  Am I missing something?

  • 0
    Intellectual 315 points
    Actually, here's how a non-interrupt context switch happens:
    1. The running task disables interrupts
    2. It flags a task to be woken as running
    3. It posts the SWI
    4. It enables interrupts - this is where the SWI occurs
    5. When switched back to, the task continues running here
  • 0 in reply to Jan Brittenson
    Guru 243980 points
    Section 12.2.7 explicitly mentions that the port interrupts can be raised by software.

    Anyway, all xxIFG flags can be cleared by software, so we know that software modifications do affect the internal interrupt logic.
  • 0 in reply to Clemens Ladisch
    Intellectual 315 points

    Do you know if this works even if the port is used for an alternate function, or even used as an output?

  • 0 in reply to Jan Brittenson
    Guru 243980 points
    As shown in the port schematics, the input registers (PxIN) are always active. (When the pin is configured for something analog, the bus keeper reports the last known value).

    So the interrupt will always work (and if the pin is not used as input, no real signal edges can interfere).

    Oh, and if you have an unused USCI module: a software reset sets UCTXIFG.
  • 0 in reply to Clemens Ladisch
    TI__Expert 5490 points
    Clemens,
    thanks for your support!

    Jan,

    do you have further questions? If not, please select "Resolved" for the post that solved your issue so this thread can be closed out.
    Thanks a lot!

    Best regards,
    Andre
  • 0 in reply to Andre Frantzke
    TI__Expert 5490 points
    Hi,

    I suppose that you were able to move on with your application as you didn't reply anymore, so I'll close this post.
    Please feel free to comment again if you look for further assistance, it will re-open the thread.

    Best regards,
    Andre
  • 0 in reply to Andre Frantzke
    Intellectual 315 points

    Not really; I'm trying to figure out how to best make it work like a proper software interrupt, but have been punting on it for now due to its complexity and distraction factor.  I only want one software interrupt following all hardware interrupts, and this would be relatively easy if the interrupt order were documented.  But like so much else about the MSP430, documentation is poor and behavior largely undefined - so can't be relied on.  My current thinking is to push the address of the SWI handler and the interrupted SR onto the stack when I want a context switch in an interrupt handler; then when the interrupt handler returns it returns to the SWI context switcher.  Since the SR loaded from the stack will enable interrupts, the SWI handler itself will be interruptible.  So if there is another hardware interrupt that will tail chain immediately before a context switch can occur.  But I need to work out all the ways it can go wrong and think those through.  This all would have been so much simpler with a proper software interrupt that is last in the service order - like on ARM (except without all the NVIC IPL stuff).  I mean, from a silicon perspective it's just a 1-bit register IFG bit that goes into the interrupt arbiter with a guarantee that's last on the service order... super cheap and simple, yet eminently practical from a software perspective.

  • 0 in reply to Jan Brittenson
    TI__Mastermind 42251 points

    The structure of the documentation on the MSP430 devices i quite simple but consists out of two parts.

    • The specification which contains all information specific to the device, e.g. pinout, int. vector table, electr. parameters, ....
    • The users guide contains information valid for the whole device family like the CPU architecture guide or module descriptions and register and bit field information

    So when looking for the interrupt order you can find this in the device specification in your case: 

    www.ti.com/.../msp430f5510.pdf

    To your original question: yes, you can use any of the MSP430 interrupts if this are not used by the module as a software interrupt by just setting the interrupt flag and the enable bit. The priority are fixed (as you can see int he interrupt vector table in the datasheet)

    For the F5510 the lowest priority interrupt is triggered by the RTC module.

    Typically several interrupts are unused in an application and can be used for that purpose.

  • 0 in reply to Stefan Schauer
    Intellectual 315 points

    The RTC looks like a good candidate... A bit messy, but I suppose that's as good as it's going to get.

**Attention** This is a public forum