• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 56 subscribers
  • Views 1103 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS/LAUNCHXL-CC1350-4: Clock issue

Dmitry Kinyov59
Prodigy 245 points

Part Number: LAUNCHXL-CC1350-4

Tool/software: TI-RTOS

Hi guys!

I'm totally stuck. I've written a program which worked fine on a LAUNCHXL-CC1350-4. On a custom CC1350 board (pretty much the same as Launchpad but in a smaller PCB size) it has some clock issue I can't resolve. The CC1350 on the board interacts through UART with another device (another PCB with it's crystal osc.). The custom CC1350 board (just as the Launchpad) receives packets from UART and transmits them to the air. Packets come every 10ms. I've measured the pace of the packets on the Launchpad and got a mean value of 1000 system clock ticks (each tick is 10us; measured with Clock_getTicks() function; the mean value is calculated on 100 values). This gives the right pace: 10ms/packet. Then I replaced the Launchpad with the custom board (the firmware is the same) and made the same measurements. In this case I've got the mean pace of 953 clock ticks per packet (== 9.53ms). The 4.7% deviation is too much for a 15ppm crystal oscillator. I've measured the osc. frequency - 24.000Mhz. I even replaced the osc. on the custom board with the Launchpad's osc. (soldered it off the Launchpad and soldered on the custom board). This didn't help. I have a number of custom boards and they all behave the same.

Could someone wise give an advise what I can tune (may be some project/TI-RTOS settings)?

Thanks in advance.

  • 0
    TI__Genius 9215 points

    Hi,

    Are you using external load caps for the crystal on your custom board? If not, have you tuned the internal caps for your custom board?

    You can find more information on this here:

    http://processors.wiki.ti.com/index.php/CC13xx_CC26xx_Crystal_Tuning

    You can also use SmartRF Studio to tune the cap-array:

    Best Regards,

    R.M

  • 0 in reply to R.M
    Prodigy 245 points

    Hi R.M

    Thank you for your fast reply. I did the folowing (in ccfg.c of my project):

    #include <ti/devices/DeviceFamily.h>
#define SET_CCFG_MODE_CONF_XOSC_CAP_MOD              0x0
#define SET_CCFG_MODE_CONF_XOSC_CAPARRAY_DELTA       0x0A
#include DeviceFamily_constructPath(startup_files/ccfg.c)

    I've tried some SET_CCFG_MODE_CONF_XOSC_CAPARRAY_DELTA  values from 0xC7 to 0x0A (there was a QFN-package CC1350 on the custom board). The mean values were changing from 953.3 (with ...OSC_CAP_MOD set to 1) to 953.8 (...CAP_MOD = 0x1, ..._CAPARRAY_DELTA = 0x0A). Is there a chance to be sure that this settings are applied properly?

    I also did some tests and figured out that the custom board worked pretty well with the Launchpad over the air. Then I noticed that the Radio core of the CC1350 on the custom board did NOT have this clock issue (unlike the CPU core). Oops! E.g. RF_getCurrentTime() returns expected values. rfc_propRxOutput_s.timeStamp is also Ok (I've implemented an FHSS algorithm through a lopped command chain: freq. change/tx/rx and again - the timings were pretty hard and it worked for Launchpad<->CustomBoard over the air). The only valuable difference between the Launchpad and the custom board I can notice: VDDS on the custom board is 2.5V

    I'm ready to try any ideas (even a bit crazy :) )

  • 0 in reply to R.M
    Prodigy 245 points
    Sorry, this didn't help.
  • 0 in reply to Dmitry Kinyov59
    TI__Mastermind 36395 points
    Dmitry,

    Its actually the 32KHz clock that is controlling the delay between two packets of 10ms. With the error of 4%, I think what has happened is that on your custom board the 32KHz oscillator has failed to start and the CC13xx has failed over to run of the internal RC oscillator. The internal RC oscillator is much less accurate and therefore you get the results you are seeing.

    My first guess is solder flux residue on the boards, I suggest doing a deep clean of the boards using alcohol/water and carefully dry them again and then try again.

    Regards,
    /TA
  • 0 in reply to Dmitry Kinyov59
    TI__Mastermind 36395 points
    VDDS of 2.5V sounds like a potential issue, can you post the schematic of the RF portion of your design?

    /TA
  • 0 in reply to TA12012
    Prodigy 245 points

    I tried to apply 3.3V to VDDS instead of 2.5V but it didn't help.

    Actually, the custom board does not have an external 32.768kHz oscillator (due to the PCB size constraints). I don't use neither Power saving nor RTC feature. Do you think that absence of this crystal osc. leads to the issue? I didn't understand your point about the relation between 10ms and 32k osc. Just to clarify, the packets come from non CC1350-powered board via UART. The CC1350 custom board (like the Launchpad) receives the packets and measures their pace (via Clock_getTicks()). This should be 10ms per packet (this is true for the Launchpad) but I measured 9.53ms on the custom board.

  • 0 in reply to Dmitry Kinyov59
    TI__Guru**** 317180 points

    If you don't have an external 32 kHz xtal: Have you set this in the CCFG.c file? It could also be that the RCOSC is running on slightly wrong frequency (depends on the calibration etc)

  • 0 in reply to TER
    Prodigy 245 points

    Thanks for the notice, TER.

    I tried to set SET_CCFG_MODE_CONF_SCLK_LF_OPTION to 0x0 and 0x3. This didn't lead to the desired result. I also set PowerCC26XX_config.calibrateRCOSC_LF (in the board file CC1350_LAUNCHXL.c) to false - it didn't work either. Are there any other settings for LF OSC I can play with?

    WBR.

  • 0 in reply to Dmitry Kinyov59
    Prodigy 245 points
    I've got an idea. In order to be sure if 32k xtal affects the system clock it needs to solder it off the Launchpad and try.
    I could check it tomorrow (I've got a cold and working remotely - therefor only software ideas today :) ).
  • 0 in reply to Dmitry Kinyov59
    Prodigy 245 points

    I've removed the 32k xtal from the Launchpad. It's got the same problem. The issue is definetely related to the 32k xtal.

    Still don't know how to fix it. 

  • 0 in reply to Dmitry Kinyov59
    TI__Genius 9215 points
    SET_CCFG_MODE_CONF_SCLK_LF_OPTION should be 0x3 and .calibrateRCOSC_LF should be true for a setup without 32k XTAL.

    Can you try to force an RCOSC calibration in your code with PowerCC26XX_calibrate();

    Documentation on PowerCC26XX_calibrate function can be found here:
    dev.ti.com/.../_power_c_c26_x_x_8h.html
  • 0 in reply to R.M
    Prodigy 245 points

    Hi R.M,

    I've tried a set of consecutive calls to PowerCC26XX_calibrate() with parameters: 1, 2 and 3 (with delays between them and without). Before and after Board_initGeneral(). I've also tried PowerCC26XX_injectCalibration() as it was recommended for user's calls. Nothing of this helped.

    The one thing that bothered me all the time was that settings I was trying to change in my ccfg.c file didn't affect the project's behavior (affected at the level of statistical error). Long story short. I included ccfg.c file into a common library for two of my executables: so called "Host" and "Device" projects (they are pretty much the same but one of them is a radio handshake initiator). It seems like the linker does not include ".ccfg" section into the projects from the library. So I moved the ccfg.c to the one of the projects and created a link to the file for the second project. Everything works pretty good for now ;)

    Thanks to all of you guys who helped me to solve the issue. I'd never come to the idea that it could be related to the 32.768kHz xtal. THANK YOU VERY MUCH!!

    PS: I figured out why it was a 4.7% deviation (or the 0.953 ratio). Here take a look at SCLK_LF_OPTION bitfield description. It says 

    0x0 XOSC_HF_DLF

    31.25kHz clock derived from 24MHz XOSC (dividing by 768 in HW). The RTC tick speed [AON_RTC.SUBSECINC.*] is updated to 0x8637BD, corresponding to a 31.25kHz clock (done in the trimDevice() xxWare boot function). Standby power mode is not supported when using this clock source.

    It seems that when CC1350 fails to calibrate an external 32k xtal it switches to the clock derived from 24Mhz. Which is 31.25kHz. 31.25/32.768 = 0.95367 (or 4.7%). The case is solved :)

    PPS: I've already implemeted the 0.953 coefficient in my projects but it was important to understand what caused the issue (also magic numbers are undesirable pieces of s.. code :) )