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.

CC2640R2F: How to disable clock-loss detection?

Part Number: CC2640R2F

Hi,

my customer would prefer to disable the clock-loss detection while operating the application. Looking at the CC26xx Driver Library, it seems that this should be possible using OSCClockLossEventDisable(). However, as the BLE stack uses RTOS, I would like to get advice how to use this function best from TI-RTOS call instead of direct driver library call.

Can you advise, please?

Best regards,
Phil

  • Hi Phil,

    There is no TI-RTOS call to disable clock-loss detection, this would have to be done using DriverLib call. Can I ask why they would want to disable clock-loss detection?
  • We would like to disable clock-loss, as we have serious problems with ESD (air discharge).
    Clock-loss is the reset source after ESD.

    What we found so far:
    Running the application in standby-mode (only 32,768 external crystal), everything works
    fine, even with 12kV air discharge.
    Once we switch the application in on-mode (24MHz crystal), air discharge of 7kV will lead to a clock-loss reset.
    If we unmount the 32,768 kHz crystal, everything works fine ESD wise, in all modes- but current consumption in
    standby is too high. Also we need the 32,768 kHz for clock purposes.

    Diverse ESD protection measures did not help so far, so we analyzed the need of clock-loss in principle:

    - Clock loss does not help in standby-mode, as the reference clocks are switched off.
    - When in on-mode (24MHz) a clock loss on LF would not bother, as we are running on 24MHz anyway.
    - Deactivating the clock loss would therefore has no disadvantage.
    - Deactivating the clock loss would help us to pass ESD approbation.

    Could you give advise, on how to deactivate clock-loss using a DriverLib call?

    Another option would of course be, to disable the 32,768kHz clock when entering on-mode, and to enable it afterwards, when going back to standby-mode. Would this be possible?

    regards,

    Martin
  • Have you considered to run the 32 kHz from the internal RC osc since not having a 32 kHz xtal seems to solve the issue? It's not clear from your post what you have set the LP clock source to when you remove the xtal.
  • Yes, we did so in the past, and it worked fine regarding ESD.

    But for this project, we also need a "clock". Here the internal RC is not precise enough.

  • The internal 32 kHz RCOSC is calibrated against the 24 MHz xosc every time the later wakes up. It's possible to run BLE on the RCOSC according to this: www.ti.com/.../swra499b.pdf, are you saying that that is not the case?
  • Yes, thats exactly, how we did it in the past. You get an accuracy of 500ppm.

    We need 20ppm.

  • Hi Martin,

    While you could possibly disable the clock-loss detection using the function above, the expected behavior remains unclear. The Power driver handles the clock control part of the RTOS and I would expect this to make it complicated to switch clocks in a controlled manner.

    Regarding the 32.768 kHZ, it would still be important even when the device is active. The LF clock will still be derived from the crystal and sourced to the AON domain (including the RTC that is basically used as the RTOS system clock).

    I'm not sure I can give you any other advice on this.
  • Ok, thanks so far. Unfortunately, digging through the posts so far, I can't find "the function above" you mentioned.

    Please advise: What exactly is the function-call , to deactivate the clock loss reset?

    regards,

    Martin

  • I was referring to the first post of the thread. The function in question is: OSCClockLossEventDisable().
  • Ups!

    Ssorry, was so concentrated on the answers, that I overlooked the question ;-)

    We will check, if this is without side effects.

    Thanks.