• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 864 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.

OMAPL138 DSP IDLE instruction handling

Nigel Paton
Intellectual 320 points
Other Parts Discussed in Thread: OMAPL138, SYSBIOS

Hi,

I'm investigating low power operation on an OMAPL138. On the DSP side I want to be able to disable interrupts (clearing GIE in the CSR), run some extra function to reduce power, call the IDLE instruction, re-instate normal operation and then re-enable interrupts. But from what I've seen the GIE bit needs to be set for any interrupts to wake the IDLE instruction up. This means interrupts can occur before normal operation has been reinstated.

In the SPRUFE8B 'TMS320C674x DSP CPU and Instruction Set' document, section 2.8.4 it talks about a PWRD 'Power-down mode field' but there is very little extra information about this field and how (or if) it affects the IDLE instruction. In particular the 'Power-down mode PD1; wake by an enabled or nonenabled interrupt' mode might be useful in this case.

I've looked at the code in sysbios and it seems to also suggest that the GIE bit needs to be enabled to allow the IDLE instruction to return. The __PMI_doIdle assembler function from the pmi_idle.s64P file sets the GIE bit as the IDLE instruction is invoked.

The problem with this is that the interrupt that wakes us up may start using modules that have been powered down and will therefore fail.

Is there a simple solution to this that I'm not seeing?

Thanks

Nigel

  • 0
    TI__Mastermind 35645 points
    Hi,

    We are working on it and will get back to you shortly.

    Thanks & regards,
    Sivaraj K
  • 0 in reply to Sivaraj Kuppuraj
    Intellectual 320 points

    Hi,

    Any update on this question?

    Thanks

    Nigel

  • 0 in reply to Nigel Paton
    TI__Guru** 116100 points

    Dear Nigel,
    Sorry for the delayed response on this.
    Thanks for following up.

    If you are looking for power save on DSP core (OMAPL138/C6748) then I would like you to suggest to refer to the following TI wiki page.



    Here,you can get frequency/voltage scaling, CPU Idle (what you asked) and sleep modes etc.,

    I hope this helps.

  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 320 points

    Hi Titus,

    Sorry for the delay getting back to you on this. The wiki doesn't really cover what I need. I've got a couple of examples:

    1) If we use a serial port for logging that only transfers data out from the device, it is something we can power down in long idle periods, it is not something that would wake the system up. When some other interrupt wakes the system up it might then cause something to be logged which would then try to access the powered down serial port. One rather messy solution would be to change the code to make sure it is powered up on every access, a much neater solution (and one we use on the ARM side of things) is when the idle task runs, disable interrupts, then power down devices not involved in wakeup events, call idle, wake up on interrupt but do not service it yet, re-enable devices, enable interrupts to allow wakeup interrupt to be serviced. This is especially important if we want to put mDDR into self-refresh and remove it's clock, anything running after this point must have it's code/data outside mDDR, if we have to put all possible wakeup interrupt handlers into internal memory it is quite a waste.

    2) Another handy thing we can do on the ARM is to exactly measure the amount of time spent in IDLE because we can collect the timestamp on either side of the IDLE (WFI in the ARM case) instruction before we allow the wakeup interrupt to be serviced. This does not appear to be possible on the DSP side of the OMAP without also modifying low level interrupt handling code to capture the wakeup time.

    So is this just the way the DSP works or is there a way that would allow me to stay in the idle task after the wake up rather than it immediately servicing the wakeup interrupt?

    Thanks

    Nigel

  • 0 in reply to Nigel Paton
    Intellectual 320 points
    Hi,

    For info we eventually worked around this using a HWI hook. SYSBIOS allows you to create HWI hooks that get called in various parts in the HWI processing. There is one that can get called at the start of a HWI. Unfortunately these are compile time configurable only so once installed you have a constant overhead of the hook being called. Fortunately in our system the code runs from RAM so we could actually disable the HWI hook when not needed and re-enable it only when needed, still had a small overhead of checking the HWI hook count but this is acceptable since it allows us to get the required functionality.

    Thanks

    Nigel