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.

CC1101 VERSION register interpretation

Other Parts Discussed in Thread: CC1101, CC110L, CC1100E, ENERGIA

While updating my local copies of datasheets, I see that SWRS061I from 20131105 changed the value and description of the VERSION register from 4 (Chip version number) to 14 (Chip version number.  Subject to change without notice).

I use the VERSION register to distinguish CC110x models: historically the following has been a reliable identifier for the specific chips I've used:

  PARTNUM       | VERSION      | Radio
  :------------ | :----------- | :------
  0             | 3            | CC1100
  0             | 4            | CC1101
  0             | 5            | CC1100E
  0             | 6            | CC430 RF1A
  0             | 7            | CC110L
  128           | 3            | CC2500

The documentation change suggests that this is not a valid use of the register. Is there another solution to identifying the particular radio, or was this change incorrect?

  • Peter, 

    We changed the packages used for all our devices, more information about this is found in a PCN (Product change notification) that all of our customer should have gotten.

    If you need the PCN, please contact your local distributor and request it.

    Regards,
    /TA

  • I found 20121105001C which appears to be this PCN.

    So to clarify, the value that identifies the functionality of the device (viz., the supported frequency bands) changed to reflect a different package that is according to that document backwards-compatible with the previous one?  There is no functional change reflected in the new version?

  • There are no changes to the devise expect for the package (and the version number).

    BR

    Siri

     

  • Siri said:
    There are no changes to the devise expect for the package (and the version number).

    Thank you.

    For future reference, changing a software-accessible version number used to identify functional differences without changing the functional differences tends to upset us software folks, since it means unnecessary changes to the validation code in firmware to make it compatible with new and old hardware.

    The data sheet really should have a table of version numbers expected to appear in any CC1101 (CC1100E, CC110L, ...) device, and what the different values indicate.  Saying only "Subject to change without notice" makes the version number pretty much useless.

    Peter

  • Hi Peter. 

    I brought your comments back to our Quality department and here is their feedback:

    “The  CC1101 device has been in full production at Texas Instruments (TI) since June 2007 with no change to the silicon die until recently.  In order to enable Cu wire bonding, which requires considerably higher bond force than Au wire bonding, a spin of the silicon had to be performed to strengthen the bond pad structures.  This change has no impact on form, fit, function, quality and reliability, i.e. neither CC1101 functionality nor performance was affected in any way.  Therefore this change was considered a minor change by TI in line with JEDEC Standard JESD46C and subsequently not included in PCN #20130422001, which was issued by TI to all distributors and direct customers on April 25th, 2013.  PCN #20130422001 describes the addition of Cu-wire as an additional bond wire option for the CC1101 products.

    The hardcoded VERSION Chip ID register – register 0x31 in the CC1101 datasheet – is intended for TI internal use and has no direct functionality or performance associated with it required in a real-world application or as described in the CC1101 datasheet.  It is used as a backup solution inside TI to detect device type and silicon revision, e.g. in cases of customer returns where the physical topside marking of the device is obscured, painted, coated or otherwise rendered not readable and not allowing secure identification.  Knowing the device version TI would then also know what changes has been made to a device from one silicon revision to another. 

    Furthermore, this register is used together with the PARTNUM – Chip ID register (0x30) for automatic device identification in e.g. TI’s SmartRF Studio tool.  Apart from this there is no intended usage applying to customers. 

    The VERSION register was not hidden in the CC1101 datasheet due to customer requests for the contents of all registers to be made public.

    The VERSION Chip ID register has changed value from (0x04) to (0x14) with the recent silicon change.  On the shipping labels this corresponds to a revision change from Rev E to Rev I.  In order to hopefully avoid similar issues in the future TI on November 5th changed the CC1101 data sheet updating the VERSION register value to (0x14) as well as updating the ‘Description’ field to the following text:

    Chip version number.   Subject to change without notice.   

    The last sentence was added to signal to customers that the VERSION register can change without a PCN being issued, i.e.  customers should not anticipate the VERSION register will hold a static value during the entire lifetime of the CC1101 device.

    Although CC1101 is a mature device, TI cannot guarantee that future silicon changes causing another change of the VERSION register will not occur.  No such plans exist today.   If a system test program in the end application needs to check the VERSION register please ensure it is change compliant, i.e.  values exceeding (0x04) are accepted.”

    BR

    Siri

  • Thank you for the additional details. 

    For what it's worth, this change apparently [1] also affected Energia support for the Anaren AIR BoosterPack, which was broken when the VERSION used to identify the CC110L changed in newer revisions of that pack.  (Energia is an MSP430+TivaC framework that brings a lot of positive visibility to Texas Instruments; breaking it is not in TI's interest.)

    I understand TI's desire to be free to change product implementation, and therefore to have internal identifiers.  This conflicts with customers ability to use those products to their full potential---including sharing software and hardware across multiple products where technically possible.

    TI should not assume that every device that uses a ChipCon-based API  is used in a unique product where an ability to identify the specific radio present is unnecessary.  Nor should TI assume that failure to fully document a register value will stop people from using it.  Humans are clever beasts: if the information is there and useful to us, we'll figure it out even if the manufacturer doesn't want us to do so, or we'll find another vendor who's more accommodating.  This is part of why open source has been such a big success.  Open documentation goes along with this, and TI has generally been a good provider of what-we-need-to-know.  (Excluding the information necessary to configure the device properly without using SmartRF Studio, but that's another issue.)

    The best approach is to go ahead and make changes as necessary, but provide to all customers the information they need to take full advantage of the product features as they change within and between product lines.

    [1] http://forum.43oh.com/topic/5896-cc3200-launchpad-and-cc110l-boosterpack/?p=51504