• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 53 subscribers
  • Views 456 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.

CC1310: RF_cmdPropTxAdv works for silicon revision 2.1 but not for revision 2.0

Sean Clark1
Prodigy 190 points
Part Number: CC1310

Hi,

I have a strange issue where my RF_cmdPropTxAdv transmit code works fine for the CC1310 silicon revision 2.1 but fails for the 2.0 version.

Symptom(s)

The RF Core seems to accept the command to transmit from the prepared data queue but doesn't actually transmit anything.

By routing the RF core's Modulation Data (MCE_GPO0) and Tx In Progress (RAT_GPO0) signals to the GPIO, I can see transmit activity and modulated data on an oscilloscope, as I expect, for silicon 2.1. For 2.0, however, I see no activity whatsoever. The TxConstantCarrierCallback() is executed, but only with RF_EventLastCmdDone, never with RF_EventTxEntryDone on the failing silicon. With the 2.1 silicon, I see RF_EventTxEntryDone, as I'd expect.

Things I've tried

  1. I was originally using the rfc_dataEntryPointer_t data entry type and suspected that a change to the more basic (?) rfc_dataEntryGeneral_t would improve things, but this failed.
  2. I was originally using my own queue definition. I reverted to using TI's own RFQueue_defineQueue() instead, without improvement
  3. I print the result of the RF_runCmd() and RF_postCmd() calls - I get a positive number, indicating no errors in submitting the request to the RF core.
  4. I have stripped all unnecessary code out of CcRfTx.c, back to the bare essentials, with no improvement.
  5. I have reviewed the Silicon A -> B errata for the CC1310. There are (IIRC) approx. 17 errata notes, only one of which affects just one of the two silicon revisions, and this note pertains to something entirely irrelevant (internal oscillator)

Please see the attached source files, which show the failing code, including overrides and PHY setup.

TIA for any suggestions,

Sean.

.

  • 0
    Prodigy 190 points

    I believe I have just embarrassed myself. As I review my submission, I notice that smartrf_settings_450m825 clearly states in the TI-generated header that the SmartRF settings export is for silicon Rev 2.1. I suspect this is the cause of the problem. I'll regenerate for 2.0 and re-try.

    In the meantime, my other blunder was to publish company and colleague names in each of the file headers - please can you delete this sensitive information?

    TIA,

    Sean.

  • 0
    TI__Guru**** 317180 points

    I deleted the attached files. Feel free to upload them again with sensitive information removed. 

    - Why are you using a CC1310 rev 2.0? We only do limited support for this version since it was replaced by rev 2.1 more than 5 years ago. 

    - I believe that the errata is missing some information, see https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/871906/cc1310-program-written-for-cc1310-rev-b-2-1-not-working-on-cc1310-rev-a-2-0. I believe this could be relevant for you based on the should walk through I did of the files you uploaded? 

  • 0
    Prodigy 190 points

    Hi TER - many thanks for the speedy reply.

    I believe due to the current chip shortage issue, suppliers might be running down old stock that hasn't been rotated properly, though I can't be certain that this is what's going on - I'll speak to our production manager when I see him next.

    I'll go through the errata you provided, as you suggest - thanks for identifying this.

    In the event that the fix is to generate correct numbers from SmartRF studio, I notice the silicon revision isn't selectable anywhere - is this hard-coded based on the Simplelink SDK and/or SmartRF version(s)? If so, which do I need to produce silicon rev 2.0 compatible values?

    TIA,

    Sean.

  • 0 in reply to Sean Clark1
    Prodigy 190 points

    Hi TER,

    We notice in SWRZ062E that Figure 2.1 illustrates the Package markings. We can't find decoding instructions for the "YMS LLLL G4" markings. is there a date code (or any other proxy) in there that can help us identify the silicon revision by inspecting the package? We want to avoid having to solder a part to a board, to then interrogate it with ChipInfo_GetHwRevision() to identify it, given that our suppliers understandably don't forward TI's Product Shipping Label to us (Figure 2.3).

    TIA,

    Sean.

  • 0 in reply to Sean Clark1
    TI__Guru**** 317180 points

    Does that mean the devices don't get delivered on a clearly marked reel? 

  • 0 in reply to Sean Clark1
    Prodigy 190 points

    Hi TER,

    Just for the benefit of others encountering this issue, I see your post here from a few years ago that decodes the package markings:

    https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/681785/cc1310-cc1310-rev-a-vs-rev-b-packing-info

    My interpretation of what you've said there is that the YMS identify <year><month><something-else>, where <year> and <month> are in hexadecimal. E.g. 7AI indicates October ('A', where Jan = '1') 2017 ('7'). Since you say that Rev A (2.0) silicon ceased production in January 2017, we identify all Rev B (2.1) as having markings of "72" (Feb 2017) or later - i.e. Year = 7,8,9,0,1,2,... Month can have any value unless Year = 7, in which case Month > 1 (in case Jan 2017 did have some Rev A production).

    It would be helpful for others if this information were present in the CC1310/26xx user manual.

    Regards,

    Sean,

  • 0 in reply to TER
    Prodigy 190 points

    Hi TER,

    Yes, that's correct. Our supplier may have a reel of several thousand, so when we purchase a few hundred, they simply ship us that quantity with a sticker identifying the part number, which is usually sufficient to uniquely identify a part. In this case, however, TI has a part that differs in behaviour according to some identifier that is not present in the part number, which I believe is unorthodox.

    I imagine it's impractical for our supplier to reprint TI's packaging label for each order they dispatch, though I admit I do not know what is typical in the industry.

    Regards,

    Sean.