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.

CCS/CC1312R: CC13xx Long Range Mode with crc & whitening?

Part Number: CC1312R
Other Parts Discussed in Thread: SYSCONFIG, , CC2500, CC1101, , CC1190

Tool/software: Code Composer Studio

FYI I am very confused with whitening in general.   For reference I am using a cc1312r chip in proprietary rf mode using Tx & Rx cmd prop advanced cmds and have 5kbps, SimpleLink Long Range selected in sysconfig.

In the Ti long range mode document, it mentions "Data whitening should always be enabled when using CC13xx Long Range Modes. Set .formatConf.whitenMode = 0x1 in CMD_PROP_RADIO_DIV_SETUP."  However when I have whitening enabled (the default sysconfig for long mode 5kbps uses whitening config "cc1101/cc2500")  My rx transactions don't work I get the PROP_DONE_ENDED status from the Rx_cmdPropRxAdv.  However, if I stop using the crc then it works or if I disable whitening then it works.  What am I missing?  Also in the document it mentions that the sync word is hardcoded for long range mode (just want to be sure this is still correct as it is currently 0x0 in the sysconfig).

Ti document referenced:

www.ti.com/.../swra642.pdf

  • Hi

    I tried to recreate your setup with the default settings for Simple Link long range 5kbps on two LAUNCHXL-CC1312R1 Launchpads, and I get a successful transmission of the packet. What SDK version and CSS version are you using? Have you changed anything else in SysConfig? 

    It is correct that the sync word is hard coded, and should be 0x0.

    Regards, 
    Vegard H

  • CCS Version: 10.1.0.00010 

    Simplelink 4.30.0.54

    sysconfig 1.6

    My sysconfig is available here:  I tried to upload directly to this forum but couldn't get it work?  Not sure what else I could be doing, did you try using the advanced packets? I am using a header that is one byte to hold the length that is in that header (one byte).  I am also filtering by address but not sure either of those would make a difference?

  • I am using the normal packetTx, I will try with advanced command to see if i am able to reproduce your issues. 

    When I try to access the file you sent on drive I  get a Access Denied. Can you try to upload the file on E2E? You should be able to add it to a reply with the "Insert file" option in the toolbar. 

    Vegard H

  • I had to change the extension from .syscfg to .txt to get it to upload, whitening is currently disabled, but if I enable it and have the crc to on in the advanced tx and rx packets then it fails.

    /**
     * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
     * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
     * @cliArgs --device "CC1312R1F3RGZ" --package "RGZ" --part "Default" --product "simplelink_cc13x2_26x2_sdk@4.30.00.54"
     * @versions {"data":"2020090214","timestamp":"2020090214","tool":"1.6.0+1543","templates":"2020090214"}
     */
    
    /**
     * Import the modules used in this configuration.
     */
    const CCFG     = scripting.addModule("/ti/devices/CCFG");
    const custom   = scripting.addModule("/ti/devices/radioconfig/custom");
    const rfdesign = scripting.addModule("/ti/devices/radioconfig/rfdesign");
    const ADC      = scripting.addModule("/ti/drivers/ADC", {}, false);
    const ADC1     = ADC.addInstance();
    const ADC2     = ADC.addInstance();
    const Board    = scripting.addModule("/ti/drivers/Board");
    const DMA      = scripting.addModule("/ti/drivers/DMA");
    const GPIO     = scripting.addModule("/ti/drivers/GPIO", {}, false);
    const GPIO1    = GPIO.addInstance();
    const GPIO2    = GPIO.addInstance();
    const GPIO3    = GPIO.addInstance();
    const GPIO4    = GPIO.addInstance();
    const GPIO5    = GPIO.addInstance();
    const RF       = scripting.addModule("/ti/drivers/RF");
    const RTOS     = scripting.addModule("/ti/drivers/RTOS");
    const SPI      = scripting.addModule("/ti/drivers/SPI", {}, false);
    const SPI1     = SPI.addInstance();
    
    /**
     * Write custom configuration values to the imported modules.
     */
    CCFG.enableBootloader      = true;
    CCFG.enableDCDC            = false;
    CCFG.dioBootloaderBackdoor = 15;
    CCFG.ccfgTemplate.$name    = "ti_devices_CCFGTemplate0";
    
    custom.prop8                                                  = ["slr5kbps2gfsk"];
    custom.radioConfigslr5kbps2gfsk.$name                         = "ti_devices_radioconfig_settings_prop0";
    custom.radioConfigslr5kbps2gfsk.carrierFrequency              = 915.0000;
    custom.radioConfigslr5kbps2gfsk.txPower                       = "0";
    custom.radioConfigslr5kbps2gfsk.whitening                     = "No whitening";
    custom.radioConfigslr5kbps2gfsk.codeExportConfig.$name        = "ti_devices_radioconfig_code_export_param0";
    custom.radioConfigslr5kbps2gfsk.codeExportConfig.symGenMethod = "Legacy";
    custom.radioConfigslr5kbps2gfsk.codeExportConfig.cmdList_prop = ["cmdFs","cmdPropRadioDivSetup","cmdPropRxAdv","cmdPropTxAdv"];
    
    ADC1.$name            = "ADC_VBATT_INTERNAL";
    ADC1.samplingDuration = "10.9 ms";
    ADC1.internalSignal   = "Battery Channel";
    
    ADC2.$name                = "ADC_TEMP";
    ADC2.samplingDuration     = "10.9 ms";
    ADC2.adc.$assign          = "ADC0";
    ADC2.adc.adcPin.$assign   = "DIO_24";
    ADC2.adcPinInstance.$name = "CONFIG_PIN_8";
    
    Board.generateInitializationFunctions = false;
    
    GPIO1.$name              = "HGM";
    GPIO1.mode               = "Output";
    GPIO1.outputStrength     = "High";
    GPIO1.initialOutputState = "High";
    GPIO1.gpioPin.$assign    = "DIO_28";
    GPIO1.pinInstance.$name  = "CONFIG_PIN_0";
    
    GPIO2.$name             = "PaEn";
    GPIO2.mode              = "Output";
    GPIO2.outputStrength    = "High";
    GPIO2.gpioPin.$assign   = "DIO_30";
    GPIO2.pinInstance.$name = "CONFIG_PIN_1";
    
    GPIO3.$name             = "InaEn";
    GPIO3.mode              = "Output";
    GPIO3.outputStrength    = "High";
    GPIO3.gpioPin.$assign   = "DIO_29";
    GPIO3.pinInstance.$name = "CONFIG_PIN_2";
    
    GPIO4.$name             = "SPI_INT";
    GPIO4.interruptTrigger  = "Falling Edge";
    GPIO4.callbackFunction  = "accelerometerISR";
    GPIO4.gpioPin.$assign   = "DIO_1";
    GPIO4.pinInstance.$name = "CONFIG_PIN_4";
    
    GPIO5.$name              = "SPI_CS";
    GPIO5.mode               = "Output";
    GPIO5.initialOutputState = "High";
    GPIO5.gpioPin.$assign    = "DIO_7";
    GPIO5.pinInstance.$name  = "CONFIG_PIN_3";
    
    RF.interruptPriority = "5";
    
    RTOS.name = "NoRTOS";
    
    SPI1.$name                 = "Accelermeter_SPI_Master";
    SPI1.spi.sclkPin.$assign   = "DIO_6";
    SPI1.spi.misoPin.$assign   = "DIO_4";
    SPI1.spi.mosiPin.$assign   = "DIO_5";
    SPI1.sclkPinInstance.$name = "CONFIG_PIN_5";
    SPI1.misoPinInstance.$name = "CONFIG_PIN_6";
    SPI1.mosiPinInstance.$name = "CONFIG_PIN_7";
    
    /**
     * Pinmux solution for unlocked pins/peripherals. This ensures that minor changes to the automatic solver in a future
     * version of the tool will not impact the pinmux you originally saw.  These lines can be completely deleted in order to
     * re-solve from scratch.
     */
    SPI1.spi.$suggestSolution              = "SSI0";
    SPI1.spi.dmaRxChannel.$suggestSolution = "DMA_CH3";
    SPI1.spi.dmaTxChannel.$suggestSolution = "DMA_CH4";
    

  • Vegard any updates?

  • If I add an end trigger and endtime to the RF_cmdPropRxAdv then I get a PROP_DONE_RXERR instead of a PROP_DONE_ENDED, which makes more sense I guess.

    The only other thing I found is that if I send a specific packet that is pretty long over 50 bytes, I also get PROP_DONE_RXERR with whitening disabled.  But only If I send a specific packet, I can send different packets that are the same length or longer and don't get the error.  Not sure if it matters but my "bad packet" starts off like this 0xbecafb1b1e55000011b4...  (the length is in the first byte and header which is 0xBE or 190).

  • Still cant get whitening to work with crc. But that specific packet w/just crc still seems troublesome.  If I change the length to 20 and append 0's after that packet I get a crc error, if I append F's I get a crc error, If I append random numbers then it works. (I understand whitening is supposed to fix this, but I cant get whitening to work...).  My RSSI is very strong -15 on both sender and receiver.  I tried moving them further apart with some obstruction to lower the rssi values  but no change in my outcome.  I also tried lowering the db power, but it didnt seem to make any difference (on my board I have a cc1190 amplifier) so l tried using the lower gain setting of the amplifier which lowered my RSSI but did not change my crc problems.  

  • It really seems like there is a bug here!

  • Hi Myles. 

    I am still trying to recreate your issue, I will let you know when I have a working setup. 

    Vegard

**Attention** This is a public forum