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.

CC1352R: Random CLK_LOSS Occurring

Part Number: CC1352R
Other Parts Discussed in Thread: CC1352P

Hello,

We are seeing CLK_LOSS messages for no apparent reason. They don't seem to be FW-related. I know there have been issues with the "P" version of this MCU. Have you logged CLK issues related to this "R" version?

Thank you.

  • We have only seen clock loss with the CC1352P with > 17 dBm out. After we defined the TXRX pin in TX (done using the SDK) we have not seen an issue even with 20 dBm. 

    Do you have some statistics when you see a clock loss? Is it dependent of output power?

    This could be tied to the layout, you can submit the design for a review on www.ti.com/.../SIMPLELINK-SUB1GHZ-DESIGN-REVIEWS

  • Could you check if you get clock loss issues if you turn off the DCDC?

  • If I disable the DCDC converter by removing the inductor, how is VDDR generated? Is there an internal LDO which takes over seamlessly or do I have to modify the FW?

    The DS mentions I should keep the connection to VDDR and VDD_RF but how is this voltage generated once the DCDC converter is disabled? It has to be internally, right?

  • Please see the mail I just sent (I had some internet issues just as I left work hence the late reply) 

    Also see https://www.ti.com/lit/an/swra640e/swra640e.pdf which contains some information on the various power options. 

  • Replying here as well so as to keep all communication on this thread.

    Regarding the layout, I see your point. The layer connecting the inductor and 20uF filter cap is layer 3 and it is quite wide but not a plane so yes, not optimal. The GND return is going through the plane so not a problem there. I am adding some mohms of resistance to the inductor but probably negligeable. Shown below is the shape connecting the inductor and caps; maybe 7 squares of series R or 7mohms, not a killer.

      

    OK, I will try disabling the DCDC converter via the syscfg file.

     

    I have not monitored the clock; as you said, you can’t do it directly because of the probe loading. It is indeed the 32KHz clock giving us errors. How do you suggest sniffing this clock?

  • Using a near field probe would be a possibility for sniffing the clock.

    Since you have added a 32 kHz xtal to your design I assume you need the accuracy a xtal gives you and you can't operate from the internal 32 kHz RCOSC?

  • That is correct. We need the accuracy and ability to go low power. If we were to use the internal 32k osc., the 48MHz osc. would need to run constantly.

  • If you set the LF clock to be 32 kHz RCOSC the 48 MHz will be turned off in SLEEP. But that would give you ~500 ppm accuracy which will cost power consumption. 

    Have you been able to test with only the LDO on? Based on that we can look into next steps. 

  • 500ppm is not acceptable. 20ppm is what we require. Why does looser accuracy cost power consumption? Can the 48MHz clock only be disabled in sleep mode?

    We turned off the DCDC enable checkbox in the syscfg setup. We are testing this now, it takes some time to trigger the error.