• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 298 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.

Using the DMA to exit the idle state - is it a good idea?

Peter Massam
Prodigy 240 points

I am using a DMA channel to transfer samples from a codec into memory.  At the moment my software uses a polling loop to detect the end of the transfer, but I feel that this wasteful.  I think that it would make more sense to use one of the IDLE procedures.  However I have a few concerns:

  • I think that the IDLE2 procedure is most appropriate.  Table 1-31 in the system guide (sprufx5c)  states that this allows an exit on any unmasked peripheral.  However the IDLE2 procedure in 1.5.5.1 begins with "Wait for completion of all DMA transfers.", not a good sign for my application.
  • What happens if the interrupt occurs before I execute the IDLE instruction?  Does the CPU come straight out of IDLE or is this a lock-up condition?

I'd be grateful for any observations, in particular if this is an unwise thing to attempt.

Peter

  • 0
    Prodigy 100 points

    Peter,

    I'm in the middle of getting Idle2 to work.  I've found SPRUFX5[A-C] a bit misleading when it comes to putting a C5515 into idle.  I've found Section 8 of SPRU317K much more enlightening and for one thing have come to understand that by leaving global IRQs disabled via INTM of ST1 is probably the most desirable method for entering/leaving idle mode, as you get a chance to fully "wake" the DSP before it's vectored of to some IRQ handler which you may have forgotten to make "idle-aware".

    Regardless, my interpretation of the idle2 configuration from the docs is that you should be able to enter some form of Idle2 configuration with a DMA IRQ being the thing that wakes the  (or other sources, in addition) DSP.  I don't believe you should need to heed the "Wait for completion of all DMA transfers", but what you will need to do is determine what PORT bits of the ICR you should not idle - if you're doing DMA then MPORT *MUST NOT* be idled and depending where you're DMAing to/from other ICR PORT bits might also need to be left un-idled.  You'll also need to pay attention to which DMA channel(s) you're using and *NOT* gate their clocks off via PCGCR1 and/or PCGCR2 regs cause if the DMA controller don't get no clocks, you don't get no DMA.

    As for what happens if the IRQ happens before the IDLE instruction, your DSP should enter and immediately exit idle and then move on to servicing the DMA IRQ.  Note that the 1st thing you must do before you configure the DSP for idle mode is to mask global IRQ via INTM of ST1 reg (HWI_disable() or whatever CSL func you use) at this point the CPU is not "listening" to IRQs but they can occur.  And don't be frightened by the requirement in the IDLE2 procedure in SPRUFX5 to:

    "4. Clear all interrupts by writing ones to the CPU interrupt flag registers (IFR0 and IFR1)."

    because although you may end up clearing the IFR flag for a pending IRQ, you will not be removing the source of the pending IRQ, in your case the DMAIFR bit associated with the DMA channel you're using and it is this source (that usually sets the associated bit in the CPU IFR) that will bring you immediately out of idle if it has been asserted while you were configuring idle w/IRQs disabled.  Were the DSP not to function in this manner, there would be to many race conditions associated with configuring the DSP in its idle mode making the whole thing worthless.

    Lastly I've found the code referenced near the end of this related post very informative:

    http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/t/114639.aspx

    Namely:

    http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer-Discussions-Components-Files/109/5127.csl_5F00_pwr.asm.txt

    http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/p/59334/211754.aspx#211754

    -Jim