• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 57 subscribers
  • Views 532 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1312R: Cannot transmit packet on CC1312R rev.F

ShuLi Chang
Prodigy 10 points
Part Number: CC1312R

Hi All:

In our original code, we set “.loDivider = 0x05” in “rfc_CMD_PROP_RADIO_DIV_SETUP_t RF_cmdPropRadioDivSetup”

And use this function to send data request:

RF_EventMask terminationReason = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, txEchoCallback, (RF_EventCmdDone | RF_EventRxEntryDone | RF_EventLastCmdDone));

We get the transmit status through “uint32_t cmdStatus = ((volatile RF_Op*)&RF_cmdPropTx)->status;”

Everything works fine on CC1312R rev.E for several hundred thousand modules.

Currently we got CC1312R rev.F chip. 

We'll get “PROP_ERROR_NO_FS” from transmit status with the same source code.

We’ve checked with spectrum, there’s not physical output.

But when we changed  “.loDivider” from 0x05 to 0x06, the transmission is normal.

Can anyone tell us any difference between rev.E and rev.F?

And why we changed the “.loDivider" and everything works fine.

Thanks!

  • 0
    TI__Intellectual 1678 points

    ShuLi,

    can you help with a few more clarifications as we look into this:

    - what frequency are you sending at?

    - are you seeing this problem on many devices? Are all rev F devices failing, or just some of them?

    I have received chip photos, so I can see the production lot trace code of the one rev F device photo I received.

    Erling

  • 0
    TI__Intellectual 1678 points

    ShuLi,

    we have a suspicion you may be using an old SDK revision which could cause this. Are you able to try one of the following:

    - Can you drive the CC1312R (rev F) on your board with SmartRF Studio? Does it allow you to transmit at the right frequency then?

    https://www.ti.com/tool/SMARTRFTM-STUDIO 

    - Are you able to load the rfCarrierWave example from latest SDK, and configure to transmit at the right frequency?

    https://dev.ti.com/tirex/explore/node?node=A__AGF6kAPbJcZ3lZ7D4sVBmg__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST 

    If any of these work, we may need to look at how we can enable your older SDK to support an rf trim feature.

    Erling

  • 0 in reply to Erling
    Prodigy 10 points

    Hi Erling:

    1. The operation frequency of our device is 839 ~ 847MHz

    2. This problem happened to 4,000 pcs Rev.F chip all failed in our factory. Another 30,000 pcs Rev. E chip works fine.

    3. We've tried with SmartRF Studio.  Rev. E works fine with loDivider  is 0x05 or 0x06.
        Rev. F didn't have any output from 839 to 845 MHz when loDivider is 0x05. But we can see output from 846 to 847MHz.

    4. We are using ver 6.10.00.29 SDK

  • 0 in reply to ShuLi Chang
    Mastermind 6130 points

    An additional question: Why have you used LoDiv = 5 for this frequency range in the first place? It looks like SmartRF Studio suggest LoDiv = 6 for this range.   

  • 0 in reply to ShuLi Chang
    TI__Intellectual 1678 points

    ShuLI,

    I see. The explanation then for why it does not work is that you are operating the device outside of specifications. See datasheet page 14, this has not changed between rev E and ref F. https://www.ti.com/lit/ds/symlink/cc1312r.pdf 

    However, when I look at the VCO range for loDIV = 6, this frequency of 839 ~ 847MHz is possible. However, please note we have not characterized the devices at this frequency (which is why data sheet is not reflecting this frequency range).  So it is not surprising that loDIV = 6 works, while loDIV = 5 does not work.

    May I ask under what regulatory requirements you are operating under for this frequency?

  • 0 in reply to Erling
    Prodigy 10 points

    Erling:

    1. This frequency is reserved for smart meter application (electric/gas/water) only in our country.

    2. Is it possible or a way for old version SDK to make it work in 839 ~ 847MHz with out change the loDivider?

    3. Can you tell us how to distinguish Rev.E & F in software manner? We may need to upgrade the software in the future, if any application scenario changed .

    We already have lots Rev.F chip and module in our factory,  so it's important for us.

    Thanks in advanced.  

  • +1 in reply to ShuLi Chang
    TI__Intellectual 1678 points

    ShuLi, to your points

    1) Ok, this is understood. Is there a public link describing this that you can share?

    2) No, it will not work to not change loDivider. Using .loDivider = 0x05 gives a sweep range (with margin) from 861MHz – 1054MHz (which are the datasheet numbers), and .loDIvider = 0x06 gives a sweep range of 718MHz – 878MHz (with margin). Some devices may operate outside of these ranges, but it is not a good solution to base your design on this as performance can vary with wafer lots.

    3) It should not be required to distinguish between these two in SW, as they are SW compatible. Both rev E and rev F may have unpredictable behaviour outside of datasheet spec, and certainly outside of the ranges mentionned above. It is possible to see rev E and F in the FCFG1 / MISC_CONF_1 /DEVICE_MINOR_REV register (page 838 in technical reference manual https://www.ti.com/lit/ug/swcu185e/swcu185e.pdf ). It has value 0x00 for rev E and value 0x01 for rev F.

    Conclusion here is that you need to use loDiv = 0x06 to get a compatible sweep range for your 839 ~ 847MHz band and account for device variations as well.

  • 0 in reply to Erling
    Prodigy 10 points

    1. Here's some information from our power company. 
    https://smartgrid.taipower.com.tw/CES/AMI_Infrastructure-2

    -> In July 2018 our government officially approved the use 839~847MHz public industry communication infrastructure exclusive channel

    2. Can you give us an idea about ".loDivider"? What does this argument for and how it's effect RF?

    3. You've mentioned about the unpredictable behavior. Please you tell us any possible issues? 

    4. If we shift our operation frequency band to 865 ~ 868MHz, shall we change the .loDivider?

    Thanks ~

  • +1 in reply to ShuLi Chang
    TI__Intellectual 1678 points

    ShuLi,

    The .IoDivider divides a reference frequency down by a factor to create the RF frequency used over-the-air. I have highlighted the ranges earlier up in this thread for value of 0x05 and 0x06. If you go for RF transmission frequency of 865-868MHz, you are within the datasheet specification of the device (and .loDivider = 0x05 gives a sweep range (with margin) from 861MHz – 1054MHz, as stated in the datasheet). If this is a solution for you, then I recommend you implement it. It is expected to work for all variants of CC1312R devices, per the datasheet specification.

    When you are outside the freq ranges mentionned earlier in this thread, you may not get a transmission. This can change from device to device, as they are not all equal and VCO freq tuning range will vary slightly. We only test for the ranges in the datasheet, so what happens outside of this range is therefore unpredictable. The chip was not designed to operate outside datasheet specification.