PWRM_sleepDSP arguments question

Finally got an update from TI expert on this module.  thank you whoever you are....

The description and example code for PWRM_sleepDSP() in spraa98b.pdf incorrectly states that there are four WUGEN event masks, there should only be three. Please ignore any reference to WUGEN_MEVT3.

When passing zero for the sleepArg parameter, the WUGEN event masks are not altered. All events currently enabled in the WUGEN event mask will be used as a wakeup event.

The function is setup to allow a specific set of wakeup events by setting the PWRM_ARGSWUGENMASK bit in the control word followed by the event masks to use, or passing in zero to use the current event masks in the WUGEN.

When passing in a specific set of event masks in the PWRM_sleepDSP() call, the current WUGEN event masks are saved before going to low power mode and then restored after the wakeup event. When passing in zero as the control word, the event masks are not saved and restored because they are not changed, they simply remain the same.

OK, so based on the answers I received and posted above, I am trying to use the mailbox interrupt (Omap3530) from GPP to cause the wakeup.

this is how I am calling the sleepDSP() function.

                            SleepArgsArray[0] = PWRM_ARGSWUGENMASK;  // not using PWRM_ARGSNOPLLCONFIG
                            SleepArgsArray[1] = 0xFFFFFBFF; // wakeup on mailbox interrupt (MIRQ10)
                            SleepArgsArray[2] = 0x0000FFFF; // no wakeups from WUGEN_MVT1
                            SleepArgsArray[3] = 0x000FFFFF; // no wakeups from WUGEN_MVT2
                            SleepStatus = PWRM_sleepDSP(PWRM_RETENTION, (LgUns)(&SleepArgsArray), 0);

But, upon sending a msg via DSPLink, it does not wakeup.  So, since there could be some confusion in the IRQ mapping we tried all of the following. The immediate wake up cases are due, I suspect to the GPTimers firing.When it does wakeup, the SleepStatus value is good.

Anybody have any experience here, or see my error?  

TIA

Dave

          SleepArgsArray [1]                    Observation

0xFFFFFBFF       –   Mailbox 0 Interrupt comes continuously from DSP to ARM

0xFFFFFFF0        -   Not Wakeup after the SleepMgr_Wakeup () function call

0xFFFFFF0F        -   Wakesup immediately after the SleepMgr_Sleep () function call

0xFFFFF0FF        -   Mailbox 0 Interrupt comes continuously from DSP to ARM

0xFFFF0FFF        -   Not Wakeup after the SleepMgr_Wakeup () function call

0xFFF0FFFF        -   Not Wakeup after the SleepMgr_Wakeup () function call

0xFF0FFFFF        -   Not Wakeup after the SleepMgr_Wakeup () function call

0xF0FFFFFF        -   Not Wakeup after the SleepMgr_Wakeup () function call

0x0FFFFFFF        -   Not Wakeup after the SleepMgr_Wakeup () function call

0x00000000          -   Wakesup immediately after the SleepMgr_Sleep () function call

SleepArgsArray [2]                    Observation

0x0000FFF0        -   Not Wakeup after the SleepMgr_Wakeup () function call

0x0000FF0F        -   Not Wakeup after the SleepMgr_Wakeup () function call

0x0000F0FF        -   Not Wakeup after the SleepMgr_Wakeup () function call

0x00000FFF        -   Not Wakeup after the SleepMgr_Wakeup () function call

0x00000000        -    Not Wakeup after the SleepMgr_Wakeup () function call

SleepArgsArray [3]                    Observation

0x000FFFF0        -   Not Wakeup after the SleepMgr_Wakeup () function call

0x000FFF0F        -   Not Wakeup after the SleepMgr_Wakeup () function call

0x000FF0FF        -   Not Wakeup after the SleepMgr_Wakeup () function call

0x000F0FFF        -   Not Wakeup after the SleepMgr_Wakeup () function call

0x0000FFFF        -   Not Wakeup after the SleepMgr_Wakeup () function call

0x00000000        -    Not Wakeup after the SleepMgr_Wakeup () function call

Your WUGEN event mask looks correct, MIRQ10 should be the mailbox interrupt from ARM to DSP. How are you invoking the PWRM_sleepDSP() function call? Is it from the idle task? Are you sending a message from ARM to DSP to invoke sleep? There are timing constraints. You cannot send the wakeup event until after the DSP is asleep. If the wakeup event happens before the sleep event, the wakeup event will be lost. If the wakeup event happens during the sleep sequence, then the sleep is aborted.

I don't understand your first observation above.

0xFFFFFBFF – Mailbox 0 Interrupt comes continuously from DSP to ARM

Are you saying the DSP never went to sleep and is now stuck sending multiple mailbox 0 interrupts or one long interrupt which is never cleared?

Hi Ramsey, thanks for response.

Our architecture has several server threads running on the DSP that get requests via DSPLink messages from clients on the GPP.  We have one such thread that will service the sleep request.  The GPP is expected to only invoke it when other threads are idle, which is reasonably assured due to out higher level design.  So it is NOT invoked from idle, but rather a threads message handling method.   The testing was done by another party, so I dont for certain know if time was allowed before sleep happens. 

How long would that take, and is there a way for GPP to determine that has happened? It is possible that constraint was violated, I will inquire..

I believe the continuous interrupt means 'over and over'  again a third party providing data.  I will ask for more details.

Thanks

The time for the DSP sleep transition depends on the sleep mode and clock speed. For hibernation at a typical clock speed would be about 1 ms, retention mode should be much faster. You can look at the PRCM registers to inspect the IVA2 power state.

PRCM.PM_PWSTST_IVA2[1:0].POWERSTATEST
0 OFF
1 RETENTION
2 INACTIVE
3 ON

Have more info.

the register you mention is reading 0xFF7 before  the sleep call and 0x555 after.  This indicates RETENTION

there is large delay after the sleep request via breakpoint inserted in GPP side.

the interrupt issue mentioned earlier, is repeated interrupts being generated from DSP->GPP.   GPP can clear but then it retriggers.

I'm a little unclear on the exact sequence of events. Here is my current understanding. Is this correct?

If I understand correctly, after the DSP wakes up again, it is unresponsive and continuously raising the DSP->GPP Mailbox interrupt. It seems that the DSP is going to retention mode as indicated by your post above. When the wakeup message is sent to the DSP, the GPP->DSP Mailbox interrupt brings the DSP out of retention mode but the thread which had called PWRM_sleepDSP() is not returning?

Hi Ramsey

I dont know about  step 7.   Will check it.  Everything else seems correct. 

We have some uart debugging string output immediately after the sleepDSP() call and do not see any output.  in the case when I believe the timer is waking it up immediately after call  (mask = 0xFFFFFF0F)  we do see the uart output and do not get the interrupts.  Perhaps it is not even sleeping in the case, but I would think rather the timer is just kicking it out.

we are a little handicapped using Greenhills probe that can not handle the DSP.

Do I need to insure the placement of the PWRM module in any particular memory segment?

Dave,

Here are some suggestions from a colleague.

• There should be no memory placement restrictions for retention mode.
• Try STANDBY sleep mode to see if that much works.

Ramsey,

here is some further testing info:  SleepMgr_Wakeup()  is a call on the Arm client side that sends the DSPLink message to wake up, naturally.

    We tested the Sleep Manager with the sleep code PWRM_RETENTION and PWRM_STANDBY in the PWRM_sleepDSP() function call with the following SleepArgsArray combination

SleepArgsArray [0] = PWRM_ARGSWUGENMASK; // not using PWRM_ARGSNOPLLCONFIG

SleepArgsArray [1] = 0xFFFFFBFF; // wakeup on mailbox interrupt (MIRQ10)

SleepArgsArray [2] = 0x0000FFFF; // no wakeups from WUGEN_MVT1

SleepArgsArray [3] = 0x000FFFFF; // no wakeups from WUGEN_MVT2

Observations:

While the Sleep code is PWRM_STANDBY

1. Mailbox 0 Interrupt comes continuously from DSP to ARM after the SleepMgr_Wakeup () function call

2. Value in this register before the sleep function call: 0xFF7 (i.e. Power domain is ON)

3. Value in this register before the wakeup function call: 0xFF6 (i.e. Power domain is INACTIVE)

4. Value in this register after the wakeup function call (i.e. after it starts sending lots of interrupts): 0xFF7 (i.e. Power domain is ON)

While the Sleep code is PWRM_RETENTION

1. Mailbox 0 Interrupt comes continuously from DSP to ARM after the SleepMgr_Wakeup () function call

2. Value in this register before the sleep function call: 0xFF7 (i.e. Power domain is ON)

3. Value in this register before the wakeup function call: 0x555 (i.e. Power domain is in RETENTION)

4. Value in this register after the wakeup function call (i.e. after it starts sending lots of interrupts): 0xFF7 (i.e. Power domain is ON)

So, to summarize, the DSP *does* wakeup on the GPP->DSP mailbox interrupt but is stuck constantly raising the DSP->GPP interrupt. The original post stated the DSP would not wakeup but now we know it does transition through the power states and wakes up. Is that correct?

Is it possible for you to use CCS to debug the DSP if the Green Hills probe cannot do this? We need to know why the DSP is constantly raising this interrupt. Its probably stuck in a loop sending a DSPLink notify event to the GPP. Maybe its doing something else. Maybe you could try to log some events on the DSP and then look at the log buffer from the GPP to get some visibility into what the DSP is doing.

your summary is correct.  I think the original statement was based on the tester not seeing uart debug output and not getting valid response message.  

I will investigate a way to get better data.  The Arm side is all done through Greenhills Multi with GHS Probe and loads the DSP through DSPLink  PROC_ module.  We will have to figure out how to debug in that environment.

Dave,

From what I understand there is no CCS to enable you to debug what is happening on DSP. You can use the Notify module to put prints at strategic locations to see what is happening on the DSP before it goes into a wrong state.

Please go through below links to see if that will help you:

http://wiki.davincidsp.com/index.php/Debugging_DSP_side_using_DSPLink_NOTIFY_module

http://wiki.davincidsp.com/index.php/Debugging_DSPLink_using_SET_FAILURE_REASON_prints

Deepali

Not sure is this is relevant:

http://tiexpressdsp.com/index.php/Debugging_the_DSP_side_of_a_DSPLink_application_on_OMAP_using_CCS

thanks.  While I do have a Blackhawk for debugging DSP side on Zoom board without worrying about the Arm, in the target system, we are using Greenhills Multi and Greenhills Probe for Arm development.  In that case I can not get to the DSP as far as I know.  I guess I could try loading it all through the Blackhawk, but I would have to create GEL files to do what Multi does now.  And I dont know if Multi .out file would be compatible.

Does anybody have experience with this arrangement?