• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 51 subscribers
  • Views 133 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.

CC2340R5: Inconsistencies QDIDs

Steffen Wiessner
Prodigy 10 points
Part Number: CC2340R5

Tool/software:

We are currently working on a new product with a CC2340R5. During the approval process, our service provider informed us that the QDIDs 196592 and 201833 are inconsistent. The link layer (LL) does not support extended advertising, but the host stack in the GAP layer does. In order for the QDIDs to match, the extended advertising would have to be removed from the GAP layer. However, this would mean that all tests would apply to the modified layer. We want to avoid that. 

Is there a solution to this problem?

Thanks,

Steffen

  • 0
    TI__Guru** 101410 points

    Hi Steffen, 

    Thank you for reaching out. 

    First of all, allow me to tell you I am a bit surprised by your observations:

    1. As their names suggest, RF-PHY QDIDs (such as QDID 196592) only cover the PHY layer. At the PHY layer, there is no concept of advertising/extended advertising or similar.
    2. Both the LL and the GAP layers are covered by the same QDID (QDID 201833). Neither the LL nor the GAP support extended advertising in the QDID 201833. 
    3. The Bluetooth SIG would never had allow one of their members to obtain a QDID with some inconsistencies 
    4. The QDIDs provided by TI for the CC2340R chipset have been referenced for more than a year without specific issues as far as I know 

     

    Also, for you to know, when you mention inconsistencies with the LL and the GAP, it make me think about the qualification issue we discussed here: https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1409123/cc2642r-bt-sig-registration-changes-starting-july-1-2024/5396139#5396139. Can you check if this could help? 

    To finish, in case additional support is required, could you please provide a list of the inconsistencies raised? Also, if you can provide the ICS file, it will help us investigate. 

    I hope this will help,

    Best regards,  

  • 0 in reply to Clément
    Prodigy 10 points

    Hi Clément,

    Here is a list of the existing incosistencies.

    LL > GAP | If [LL] and [GAP] (8/3) are Supported then [LL] (3/1a) is Mandatory

    LL > GAP | If [LL] and [GAP] (8/4) are Supported then [LL] (3/5a) is Mandatory

    LL > GAP | If [LL] and [GAP] (20/5) are Supported then [LL] (3/4b) is Mandatory

    LL > GAP | If [LL] and [GAP] (20/6) are Supported then [LL] (3/1a) is Mandatory

    LL > GAP | If [LL] and [GAP] (20/7) are Supported then [LL] (3/5a) is Mandatory

    LL > GAP | If [CORE] (40/3) and [GAP] (8/3) are Supported then [LL] (3/1a) is Mandatory

    LL > GAP | If [CORE] (40/3) and [GAP] (8/4) are Supported then [LL] (3/5a) is Mandatory

    LL > GAP | If [CORE] (40/3) and [GAP] (20/5) are Supported then [LL] (3/4b) is Mandatory

    LL > GAP | If [CORE] (40/3) and [GAP] (20/6) are Supported then [LL] (3/1a) is Mandatory

    LL > GAP | If [CORE] (40/3) and [GAP] (20/7) are Supported then [LL] (3/5a) is Mandatory

    Best regards,

  • 0 in reply to Steffen Wiessner
    TI__Guru** 101410 points

    Hi, 

    Thank you for providing this list. 

    I confirm these inconsistencies are caused by the updated ICS. You should use the TCW (ES-25636) to work around it.

    For reference, please review https://qualification.support.bluetooth.com/hc/en-us/articles/28012390144397-Waiving-Consistency-Check-Inconsistencies-for-Inter-Layer-Dependencies-in-Unmodified-Locked-Layers and https://bluetooth.atlassian.net/browse/ES-25636

    Best regards, 

  • 0 in reply to Clément
    Prodigy 10 points

    Hi Clément,

    our service provider has sent us the following reply to your last message:

    In my opinion, the Waiver ES-25636 cannot be used for this scenario, because it is only valid for unmodified locked layers where ICS didn’t previously exist. The used LL and GAP have been qualified with TCRL 2022-1 and all the ICS mentioned in the consistency check do exist.

    For this scenario, I could not identify any existing waiver that can be used.

    If you like, I can request a new waiver for this scenario, but I don’t think it will be successful.

    In my opinion, TI needs to create a subset of the host QDID and remove the extended advertising features from the GAP layer.

    Best regards,

  • +1 in reply to Steffen Wiessner
    TI__Guru** 101410 points

    Hi Steffen,

    Thank you for telling me. 

    In order to wave the LL/GAP inconsistencies, we have produced the DN subset DN Q312647. Please reference this one instead of QDID 201833.

    Best regards,