the question about PSC

For which function call does it stop at this loop? All of them? There may be other problems related to whichever module is being enabled.

Yefei,

The register you're looking at in the while loop is a transition status register.  It's only going to have the relavent bit set while the transition is occurring.  If the transition happens before it's read, then you'll be trapped by the loop as you've observed.  This registers primary function is for debugging the state if the change isn't occurring for some reason.

You'll only want to look for the MDSTAT to be in the enabled state.

Best Regards,

Chad

void PSC0_lPSC_enable(Uint8 PD, Uint8 LPSC_num)
 {

  *(Uint32*) (PSC0_MDCTL+4*LPSC_num) = (*(Uint32*) (PSC0_MDCTL+4*LPSC_num) & 0xFFFFFFE0) | 0x0003;
  PSC0_PTCMD = 0x1<<PD;     //GO[0]=0x1
  while( (PSC0_PTSTAT & (0x1<<PD) ) !=0) ; /*Wait for power state transition to finish;GOSTAT[0]=0*/
  while( (*(Uint32*)(PSC0_MDSTAT+4 * LPSC_num) & 0x1F) !=0x3);
}

All of them .

I call the first function PSC0_IPSC_enable(0,0) ,when it excete at while( (PSC0_PTSTAT & (0x1<<PD) ) !=0) ; ,it stoped.I think the relavent bit of PSC0_PTSTAT is not change,but why it isn't change.

thanks

void PSC0_lPSC_enable(Uint8 PD, Uint8 LPSC_num)
 {

  *(Uint32*) (PSC0_MDCTL+4*LPSC_num) = (*(Uint32*) (PSC0_MDCTL+4*LPSC_num) & 0xFFFFFFE0) | 0x0003;
  PSC0_PTCMD = 0x1<<PD;     //GO[0]=0x1
  while( (PSC0_PTSTAT & (0x1<<PD) ) !=0) ; /*Wait for power state transition to finish;GOSTAT[0]=0*/
  while( (*(Uint32*)(PSC0_MDSTAT+4 * LPSC_num) & 0x1F) !=0x3);
}

PSC0_PTCMD = 0x1<<PD; ------------------

then I think the state transition is not occured .

because of the relavent bit of PSC0_PTSTAT is not change ,so it keeps infinite loop.but why it doesn't change.

I test the relavent bit of MDSTAT,it doesn't change too.

Is there any other reasons cause this problem?

thanks

It may just be my old eyes, but I cannot clearly read the excerpt you pasted above. And also by the way, I cannot easily read black text under dark red highlighting.

From which document did you pull out the excerpts?

Did you understand Chad Courtney's explanation about the bit you are testing?

Did you copy this code from somewhere or is it original code you have written? If you copied it from a TI example, please point to where it was copied from.

RandyP said:

It may just be my old eyes, but I cannot clearly read the excerpt you pasted above. And also by the way, I cannot easily read black text under dark red highlighting.

From which document did you pull out the excerpts?

this is in the "OMAP-L137 Applications Processor System" page 117 and 118

RandyP said:

Did you understand Chad Courtney's explanation about the bit you are testing?

Sorry ,I try what he said ,but it can't work also.

RandyP said:

Did you copy this code from somewhere or is it original code you have written? If you copied it from a TI example, please point to where it was copied from.

I copy it from "evmomapl137_dsp.gel",and I think it may not be any mistakes.

thanks

I misread the line of code in question up above, and my earlier response was incorrect.  The on thing I could think of is if the variable PTSTAT was not declared volatile, that it could be optimized to read once and the while loop is being assessed on stale data.  That said, I had assumed this was on either the C6472 or C6474 devices since it was in the C64x Multicore processor area which I know the compiler for it can optimize it out.

Have you opened a memory window to the address to see what the value is while you're executing?  Is the bit getting set to 1 and never changing?

Have you viewed the assembly code to see what's executing and verified that it's pulling the current PTSTAT every time it assesses the while loop?

I'd start there with the simple debugging.

Best Regards,

Chad

Chad's comments will probably lead you to the solution. If so, please come back and click Verify Answer on his post above, or write up a description of what you did to solve this and click Verify Answer on it after you post it.

For completeness, another TI expert Mukul sent an email pointing out that the last enable you do, for PSC1 Module 31, is for the Shared RAM module. This module is on the PD1 domain and not the PD0 domain, so the function call for it should be PSC1_lPSC_enable(1, 31); instead of (0, 31). This is also wrong in the gel script. But the Shared RAM is enabled by default, and disabling is not supported, so this error should be corrected but this fix will not likely affect your lockup problem.

Addressing Chad's comments above are the most likely to solve your problem. And please let us know whether it does or does not solve the problem.

I'm sorry for didn't  replying your post,beacause I am so busy these days.

Finally,we found the problem,as the picture says:

the PSC is related to all the CVDDs,and I didn't connect K6.

It's my responsibility.

Is there any remedial measures to solve this problem,and does this one of the CVDDs decided we can't use PSC anymore?

thanks to you all.

yefei,

Can you update your PSC enable function to include a print statement so that we know which module is freezing?

void PSC0_lPSC_enable(Uint8 PD, Uint8 LPSC_num)
 {

  GEL_TextOut("\tPSC0 Enable on Domain %d, LPSC %d\n","Output",1,1,1,PD,LPSC_num);

  *(Uint32*) (PSC0_MDCTL+4*LPSC_num) = (*(Uint32*) (PSC0_MDCTL+4*LPSC_num) & 0xFFFFFFE0) | 0x0003;
  PSC0_PTCMD = 0x1<<PD;     //GO[0]=0x1
  while( (PSC0_PTSTAT & (0x1<<PD) ) !=0) ; /*Wait for power state transition to finish;GOSTAT[0]=0*/
  while( (*(Uint32*)(PSC0_MDSTAT+4 * LPSC_num) & 0x1F) !=0x3);
}