The setting problem for System clock, PLLSYSCLK

Hi Sandy

please refer to section 1.8 -Clock Control in the Concerto device TRM. There is a proceedure listed in sub-section 1.8.5 to have control subsytem configure the PLL.

if M3 sets PLL to some X1 freq and then C28x sets it to a different freq. later on, device will continue to operate as per X2 frequency. Users have to make sure that they won't over clock the system by making sure the dividers are set as needed (M3SSDIVSEL, SYSDIVSEL), especially when C28x is configuring the PLL it doesn't have access to M3SSDIVSEL.

Please let us know if you have any more questions or need clarifications from section 1.8 of TRM.

Best Regards
Santosh

Hi Santosh,

      Thank you for your answer.

      Now I still can't set the PLLSYSCLK by C28x .Can you provide more detailed steps or code.

Thanks~~

Sandy

Hi Sandy,

we don't have any other examples at this point other than the detailed steps in the TRM. Can you copy paste your M3 and C28x code - we can have a look at it.

Can you also give more details about the error?

C28x code is not able to read/write to the PLLSYSCLK register? how did you identify that C28x is not able to set PLLSYSCLK,

 

Best Regards
Santosh

 

I am also trying to set clock from C28 and I cannot.

Working with M35 controlcard using on-board XDS100V2, CCS 5.3, ControlSuite v160

If follow procedure from TRM, from within C28 code EALLOW must be issued, then the bit #0 in CCLKREQUEST has to be  set to 1 before changing clock controlled registers. Also, in debug mode CCS via JTAG overrides this EALLOW bit in ST1 and JTAG has full access to all protected registers.

Apparently, not: in any C28 sample project on breakpoint in debug mode the CCLKREQUEST is visible, but changing it is impossible - it ALWAYS reads as 0x00000000.

Similarly, if running M3 project, on breakpoint in debug mode but changing MCLKREQUEST is impossible - it ALWAYS reads as 0x00000000.

If truing to do it in run time, the following code cannot change it either:

volatile Uint32 clk_set[5];

void Change_CLK_from_C28(void)

{                                    //AFTER CCS  |  AFTER NORMAL
                             // Programmed FLASH  |  POWER-UP
  clk_set[0] = (M3PllRegs.SYSPLLCTL.all); // 0x03 | 0x03
  clk_set[1] = (M3PllRegs.SYSPLLMULT.all);// 0x0F | 0x0F
  clk_set[2] = (M3PllRegs.SYSPLLSTS.all); // 0x01 | 0x01
  clk_set[3] = (M3PllRegs.SYSDIVSEL.all); // 0x01 | 0x00<<<< DIFFERENCE which changes M3 clock after CCS programmed flash
  clk_set[4] = (CtoMIpcRegs.CCLKREQUEST); // 0x00 | 0x00

// if (clk_set[3] == 0x0)
  {
    asm (" EALLOW");
    CtoMIpcRegs.CCLKREQUEST = 0x01;
    if (CtoMIpcRegs.CCLKREQUEST == 0x01)
    {
      asm (" EALLOW"); //<<< break point here NEVER hit
    }
    else
    {
    asm (" EDIS"); //<<< break point here ALWAYS hit
  }
}

How someone can do it?

Is (are) here any other setting(s) , like privileged mode in M3?

Regards,

Igor

Thank you, Santosh

For everybody: magic KEY is 0xA5937EC0

need to write a combination of 0xA5937EC0 +0x01 = 0xA5937EC1 to change ownership of registers.

Igor

I realize this is a dated post that I'm responding to. However, I am in the trenches of Concerto clock initialization and am curious about this clock semaphore that I see mentioned in the TRM SPRUH22G. However, I have scoured that document and can find no reference to the above mentioned KEY values. The only reference that I've seen is in ...\MWare\v207\driverlib\ipc.h. So Santosh or whomever, please specify where in the TI documentation that this special clock setting protocol is documented. Thank you.
Best regards,
Steve Ciricillo

Stephen,

are you trying to initialize clocks from C28x? please refer to section 1.8.5 and section 1.12.8 of concerto device TRM www.ti.com/.../spruh22g.pdf .

From M3 , this register is defined in section 1.13.11.7 and from C28x side the register is defined in section 1.13.12.7

Hope this helps.


Best regards
Santosh Athuru

Thank you Santosh,
I see now the section I needed. I am initializing the M3 clock by the way.
Best regards,
Steve

Thank you Vivek,
You've clearly shown me the section I had missed.
Best regards,
Steve C.