Problem of C6655 power-down/wake-up

Hi,

Can you confirm that you are following step 3 in 3.4 Main PLL Wakeup:

"Follow the PLL reset sequence in Section 3.1.1 (steps 3 to 9) to reset the PLL. Wait for the PLL to lock and to switch from bypass to PLL mode."

Are you using a C6655 EVM or is it a custom board?

Hi, Aditya.

Thank you for Reply.

I follow the 3.4 Main PLL Wakeup.

This phenomenon occurred in C6655EVM on.

Running programs is a program to repeat the Power-Down/Wake-up.

For several tens of minutes about repeating the "Suspend" and "Resume" of CCS,

The following warning has been confirmed by CCS.

======

C66xx_0: Trouble Halting Target CPU: (Error -1060 @ 0x0) Device is
not responding to the request. Reset the device, and retry
theoperation.
If error persists, confirm configuration, power-cycle the board,
and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation
package
5.1.232.0)

======

Best Regard.

hamada

Hi,

Please let me know if I understand you correctly: are you saying you are repeating the power down/wakeup over 'tens of minutes' and you see the CCS connection error at the end?

Assuming my understanding is correct:

1) Is there a reason you are repeating this sequence multiple times? What is your end goal?

2) Have you tried running the sequence just once and do you see the same CCS error?

3) After CCS disconnects, can you try connecting to the DSP's ICEPICK and inspect the status of the core itself? If the ICEPICK is successfully connected but the DSP core is not accessible, this would indicate the clock may be powered down. However, if the ICEPICK can't be connected then the entire device is being held in reset for some reason.

4) What emulator are you using? Please also make sure your emulation drivers are updated.

Hi, Aditya.

Thank you for Reply.I will answer questions.

1) At the request of our customers, we are to bring down power consumption.

2) It has not been confirmed only went once.

3) After the failure reproduced, remove the connect of CCS while to On the power of EVM,
    It was not possible to connect the core problem occurs when you connect again.

   It is possible to connect the cores do not break under the same conditions.

4) I am using the on-board emulator XDS200.

Best Regards,

hamada

 1072.project.zip

Hi 

I attach the project "pll_test_L2SRAM_NG" trouble-prone project "pll_test_L2SRAM" that does not happen defective.

(work with on EVM)

There are differences in function of bootcfg_setup_core_pll c6000_bootcfg.c The difference between the two projects.

It is that you do not run by commenting out the step2 is pll_test_L2SRAM.

pll_test_L2SRAM_NG Change the conditional branch of the step3 step2, I am that you do not run the step2.

I think from the above results, the alignment is as though they were due to failure.

However, we do not know why the problem occurs due to alignment is useless.

Please tell me if there is a person who can see.

best regards,

hamada

hamada said:

  It was not possible to connect the core problem occurs when you connect again.

   It is possible to connect the cores do not break under the same conditions.

I am sorry, but I do not understanding what you are trying to say here. Can you please elaborate? I will take a look at the project and get back.

May I ask who is the customer?

Hi, Aditay.

Thank you for reply.

My Customer is required to PLL power down and wake up in order to reduce the power consumption.

However, customers have reported to us phenomenon of the CPU malfunctions sometimes occurs when run the PLL wake up and  power-down sequence.

So, we have created test program that is attached to the above in order to confirm the phenomenon on EVM6657. (This test program is repeat the PLL power-down and wake-up.)

This test program has been reproduced the same phenomenon as the problem that is occurring in the customer board.

Please let me know, If you have a something information in regard to this phenomenon.

> May I ask who is the customer?

I can not be disclosed the customer information in open community.

I think if you absolutely necessary that can be used to inform through the local TI FAE.

Best Regards,

hamada

Hi, Aditay.

I am sorry.
This case and how is it?

It has gotten a reminder from the customer,

I am happy if you could tell me if there is some progress.

best regards,

hamada

Hi, Aditay.

I am a team member with "hamada".
Thank you for your support.

We have further investigated the C6655 PLL power down / wake up issue,
and would like to report the phenomenon in details.

We have tested with three EVMs.
Although we use the PLL power down / wake up sequence that is described by the "3.3 Main PLL Power Down",
"3.4 Main PLL Wake Up" and "Section 3.1.1 (steps 3 to 9)" on the PLL user guide(SPRUGV2F), 
CPU seems to be hung when the main pll to bypass mode in PLL power down sequence.

So, We consider the procedure described in PLL user guide(SPRUGV2F) is not enough.
Could you please analyze this phenomenon?

Please see the attached project which we can reproduce the phenomenon using the C6657 EVM and CCS.
We have confirmed in the following way.
 

1. CPU to hung when the main pll to bypass mode in PLL power down sequence.

==c6600_bootcfg.c==

void bootcfg_plloff()
{
/***/
        bootcfg_unlock_kikker();
/***/

        PLLC.SECCTL.BIT.BYPASS = 1;     // <--  CPU hung !!!
        op_nop();
        op_nop();
        op_nop();
        op_nop();

        PLLC.PLLCTL.BIT.PLLPWRN = 1;

/***/
        bootcfg_lock_kikker();
/***/
}

2. There are individual differences by C6657EVMs in the incidence of the phenomenon.

    We ran the same out file of attached project using three EVMs.

    two EVMs : Problem occur when repeat a few dozen times PLL power down and wake up.

    one EVM  : Problem does not occur almost. (Problem occur when repeated several hours)

3. As follows, the problem does not occur by increasing the frequency division ratio before the pll is bypassed.

   (It is experiments, Originally, we should change the divison ratio after the PLL bypass.)

==c6600_bootcfg.c==

void bootcfg_plloff()
{
/***/
        bootcfg_unlock_kikker();
/***/
        PLLC.SECCTL.BIT.OUTPUT_DIVIDE = 4 - 1;  // to slow clock, /4 ~ /16
        op_nop();
        op_nop();
        op_nop();
        op_nop();

        PLLC.SECCTL.BIT.BYPASS = 1;  // <--  CPU not hung up!!!
        op_nop();
        op_nop();
        op_nop();
        op_nop();
        PLLC.PLLCTL.BIT.PLLPWRN = 1;

/***/
        bootcfg_lock_kikker();
/***/

}

Best regards,
H.U

H.U.,

Thank you for your observations. I will attempt to reproduce this at my end and get back.

Hello,

Sorry for the delay. I have run both your executables on two different platforms (EVM and an internal testing board) for an overnight test but neither of them are showing this problem.

I am not sure what to make of this behavior. Is this a strict requirement for the customer? Have they explored all other power savings methods like hibernation?

These steps should be executed any time before writing BYPASS=1 in the SECCTL register. This applies whether executing the Main PLL init sequence, powering down the PLL or executing PLL wake up.

Thanks to everyone on this thread for your debug effort and feedback.

- In PLLCTL, write PLLEN = 0 (bypass enabled in PLL controller mux)
- In PLLCTL, write PLLENSRC = 0 (enable PLLEN to control PLL controller
mux)
- Wait 4 cycles of the reference clock CLKIN (to make sure the PLL controller
mux switches properly to the bypass)

Note on documentation: The Main PLL init sequence accounts for this, but the power down and wakeup sequences do not. The latter two sequences in the PLL UG will be updated to reflect these steps.

Hello Aditya,

Thank you very much for your reply.
I am aware that the user guide will be updated.

Please allowed to check about another problem for PLL UG.

Main PLL initialization procedure Step2 is described as follows.

====
2. Check the status of BYPASS bit in SECCTL register, execute following steps if
   BYPASS == 1 (if bypass enabled), if BYPASS == 0 then Jump to Step 3
====

It seems that PLL multiplier and devider is setting without PLL bypass.
because SECCTL_BYPASS is not set by step2 when SECCTL_BYPASS == 0.
So, I think this step2 is wrong.
Step2 should be executed when SECCTL_BYPASS ==  0 (if bypass disable).
My thinking is correct?

Best Regards,
H.U

H.U, thanks for your comment. I will get back to you on this.

H.U.,

The BYPASS conditionality in step 2 is correct.

Hi Aditya,

Do you say that the described in PLL UG as follow is correct?

====
2. Check the status of BYPASS bit in SECCTL register, execute following steps if
BYPASS == 1 (if bypass enabled), if BYPASS == 0 then Jump to Step 3
====

Is it means that can be safe to change the PLLM and PLLD, if PLL controller is bypassed in spite of the SECCTL_BYPASS ==0 (in PLL mode)？

Best regards,
H.U

H.U.

Yes, our design expert confirmed that the sequence in the UG is correct. Are you facing any problems?

Hi Aditya,

No, I don't have other problems.
However, I was thinking that PLL multiplier and devider should not be changing when PLL is not bypassed in general.
So, I asked the question above.

I understood the procedure of PLL in the C665x devce by your comment.
I got to clear all my questions.

Thank you for your support.

Best Regards,
H.U