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.

LAUNCHXL-CC1312R1: Smart RF studio 7 (2.25.0) TXCO config

Part Number: LAUNCHXL-CC1312R1
Other Parts Discussed in Thread: CC1312R, SYSCONFIG, CC1310

Hello,

I'm trying to use SmartRF studio 7 (2.25.0) to configure the CC1312R eval board to use the TXCO.  I have proved an output by swapping across the hardware (though running the TCXO from VDDS rather than DIO30).

Page 26 here suggests that the TCXO settings are in 'device configuration' but I can't find that menu.  The closest one only has an option to set the RF output between diff or single ended, but nothing on the input clock.

https://www.tij.co.jp/jp/lit/an/swra640f/swra640f.pdf?ts=1656490895088&ref_url=https%253A%252F%252Fwww.google.com%252F

My aim is to produce a fixed frequency CW output with as little phase noise as possible.  There is section 13.3 here covering phase noise, but this is on the code export output - is there any information as to how to do this using the override editor for individual registers?

https://www.ti.com/lit/an/swra682/swra682.pdf?ts=1655300689499&ref_url=https%253A%252F%252Fwww.google.com%252F

  • Hi Pete,

    The settings at page 26 you are referring to, are to be configured inside sysconfig in your Code Composer Studio application. There is no support to enable TXCO from smartRF studio. You can apply the settings you are mentioning in sysconfig inside the proper RF example (select which example depending on the used stack and RF technology) that you find in the simplelink SDK.

    Regards,

    Fausto

  • Hi Fausto,

    Ah ok, thanks - I thought that the line "SmartRF Studio 2.17 or earlier does not support TCXO" meant that newer ones do. I suppose it means that it was written at a point in time when 2.17 was the latest and it didn't currently support, rather than my reading that 2.18 and newer does include support.

    I was hoping I would be able to conclude the bench testing with SmartRF studio before handing over to software to implement later - but will download Code Composer Studio and see if I can get it to work.

    Thanks,

    Pete

  • Hi Pete,

    No, unfortunately smartRF studio 7 does not have support for TCXO in any of the released versions. I confirmed this with the developers of the tool.

    Best regards,

    Fausto

  • Hi Fausto,

    Thanks for the help so far.

    I have made some progress on this - using CSS I have used the CC1310 launchpad and assessed the loop bandwidths as per swra682.  I have then got the rfCarrierWave demo for the CC1312R1 launchXL tr rtos 7 version which boots the CC1312R board ok.

    I altered the hardware to use the TCXO rather than the crystal, but rather than GPIO powered this is hung from VDDS.  This still works with RF Studio, and with the default settings of the rfCarrierWave demo.

    However, I'm struggling with two things:

    - I can't see where the smartrf_settings can be migrated into this to tune the Tx output.

    - I can't tune the syscfg file to properly define it to run from the TCXO. swra640 shows the mods required within the device configuration, but I'm struggling to easily swap across the 'power' settings.  I don't really need the 'Enable TCXO Function' initially, as I've left the TCXO permanently powered - but I can't work out how to disable the need for this function.  Nor can I find any documentation on the function declaration for the GPIO assignments.  The main c file calls up a board header file of ti_drivers_config.h but I can't find this in my filestructure (nor with a search on the drive) to see how to get the GPIO assignment declared properly for when I do migrate the TCXO across to GPIO control.

    Sorry if this is all a bit basic, I'm coming at this from the hardware angle so may need some spoon feeding with the software - apologies in advance!

  • Hi Pete, 

    Here is the answers to the 2 questions of your post:

    - the normal way of configuring the RF settings is to directly modify the values inside sysconfig. Assuming you are using a proprietary protocol, you can find more information in the proprietary RF user's guide https://dev.ti.com/tirex/explore/node?node=AKo8sAEb13jFuenht-NmOQ__BSEc4rl__LATEST . More specifically in the System configuration tool section you can find more details about how to select RF settings from sysconfig https://dev.ti.com/tirex/explore/node?node=AKo8sAEb13jFuenht-NmOQ__BSEc4rl__LATEST . If you really want to export settings from smart RF studio, this will require a bit more work, but it can be done and details are also found in the section linked above or in the following guide (https://software-dl.ti.com/lprf/smartrftm_studio/docs/help/html/cmd_code_export.html). 

    - There is no explicit way in sysconfig to remove the Enable TCXO Function. If your TCXO is always powered up you could create a function and leave it empty. Remember to modify this function once you modify your design and connect the TCXO to a GPIO.

    ex:

    void Power_enableTCXO(bool turnOn)
    {
    
        // do nothing if TCXO is always powered-on
    
    }

    To control GPIOs, you need to define a new GPIO you intend to use from the sysconfig interface. Then use the functions defined by the GPIO driver (find documentation in the docs/drivers/tidriversAPI.html -> GPIO.h) to control the state of the pin.

    Let me know if something is not clear. 

    Best regards,

    Fausto 

  • Hi Fausto,

    Thanks - I'm happy to do everything in code studio, I've found the reconfig bit now to get the frequency etc set - and that is now working fine when it thinks it is running from the crystal.

    However I'm still failing to get it running from TCXO mode.  I've tried adding the empty function as you suggested, and running with a breakpoint in that (I added it into rfCarrierWave.c in the function declaration section) it does go through it - but then continuing to run it is getting stuck in a while (1) in PowerCC26X2.c

    * ======== switchXOSCHF ========
    * Switching to XOSC_HF when it has stabilized.
    */
    static void switchXOSCHF(void)
    {
    bool readyToCal;
    unsigned int key;

    key = HwiP_disable();

    if (!PowerCC26X2_oschfTrySwitchToXosc()) {
    /* Unable to switch to XOSC after we were informed it is ready to
    * switch. It is fine if we spin, there is no sensible recovery
    * mechanism from such an error.
    */
    while(1) ;
    }

    Why would it be trying to switch to the HF OSC when I have set it to use the TCXO? IS there anywhere else other than these three steps which need altering to define running from the TCXO rather than the crystal?:

    - TI Devices > Device Configuration

    - TI Drivers > Power

    - Power enable routing adding to code

    Thanks for your patience,

    Pete 

  • Hi Pete,

    Which SImplelink SDK version and compiler are you using? There is a bug in simplelink SDK 6.10.00.29 which results in the same behavior you are seeing when switching from internal oscillator to the external TCXO. This bug is already fixed internally and will be released in the next Q2 Simplelink SDK. 

    This is due to slightly change in timing. You can try adding a small delay before switching, modifying switchXOSCHF to the following:

    static void switchXOSCHF(void)
    {
        bool readyToCal;
        unsigned int key;
    
        key = HwiP_disable();
    
        delayUs(5); 
    
        if (!PowerCC26X2_oschfTrySwitchToXosc()) {
            /* Unable to switch to XOSC after we were informed it is ready to
             * switch. It is fine if we spin, there is no sensible recovery
             * mechanism from such an error.
             */
            while(1) ;
        }

    Let me know if this fixes the issue.

    Regards,

    Fausto

  • Hi Fausto,

    Excellent - yes I am using 6.10.00.29, and that gets round it. 

    So the next bit, trying to get the minimum phase noise (but while trying not to bring up loads of spurious) would be to assess altering the loop bandwidth (so back to swra682 section 13.3 loop bandwidth.  This was what I was using the smart RF studio output for on the 1310, as that section of code is in the smartrf_Settings.  I can't see an equivalent in the RF stack or RF system of syscfg - could you point me in the right direction please?

    Thanks,

    Pete

  • Hi Pete,

    To add these overrides you can use the "application overrides" feature in sysconfig. From the sysconfig interface, open Custom -> Custom PHY settings -> Code export configuration -> application override:

    Then create a header file ex. my_overrides.h and add a macro containing the overrides than need to be added to the pOverrides struct:

    #ifndef MY_OVERRIDES_H_
    #define MY_OVERRIDES_H_
    
    #define MY_OVERRIDES() \
    /* Synth: Set loop bandwidth after lock to 20 kHz (K2) */ \
    (uint32_t)0x0A480583, \
    /*Synth: Set loop bandwidth after lock to 20 kHz (K2) */ \
    (uint32_t)0x000005A3, \
    /* Synth: Set loop bandwidth after lock to 20 kHz (K3, LSB) */ \
    (uint32_t)0x7AB80603, \
    /* Synth: Set loop bandwidth after lock to 20 kHz (K3, MSB) */ \
    (uint32_t)0x00000623, \
    /* Synth: Set FREF = 8 MHz */ \
    (uint32_t)0x000684A3
    
    #endif /* MY_OVERRIDES_H_ */

    Be careful not to add a comma on the last override at it is already added by sysconfig after the macro name. Also the comment in the macro need to be in the style " /* comment here */ " to be able to have multiline macros as above. 

    There are other more hacky way to modify the ti_radio_config.c file to add overrides to the pOverrides struct described in this other post https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/849768/ccs-cc1312r-sysconfig-radio-overrides/3142651?tisearch=e2e-sitesearch&keymatch=pOverrides%20sysconfig#3142651. However they either require to disable sysconfig for the generated radio files or to create a larger new override structure at runtime.

    Regards,

    Fausto 

  • Thanks Fausto, thats brilliant.  There seems to be a lot of breakthrough of the 32kHz clock onto the output, which is then more obvious with the reduced noise floor, and hampers the usefulness of the lower floor - so I'll have a see whether there is anything I can do about this.  However in terms of the control and setup (unless there is a way to disable the 32kHz while running?) this has answered the questions I had - thanks for your support!