• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 699 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.

CC2640R2F: Features missing when porting Host Test example from older SDK to new version 5.30.00.03

Wolfgang Wendler TI
Intellectual 2470 points

Part Number: CC2640R2F
Other Parts Discussed in Thread: BLE-STACK, CC2640, CC2340R5, CC2340R2

Tool/software:

Hi,

Asking on behalf of my customer:

Porting an application from CC2640 to CC2640R2. The original application is based on the Host Test example, so we're basing our new application on the Host Test example from the SimpleLink CC2640R2 SDK, version 5.30.00.03. We're also migrating from the BLE-Stack to the BLE5-Stack. The CC2640/CC2640R2 is only used as a network processor, hence our choice of using Host Test. Our application in itself is run on another MCU (our main MCU).

 

During our work we've observed a number of changes that have an impact on us. I'll list them below just for clarity and for context.

 

  1. With the BLE5-Stack it's no longer possible to build the Host Test application both as central and as peripheral. This is covered in https://sir.ext.ti.com/jira/browse/EXT_EP-10234.
  2. With the BLE5-Stack it's no longer possible to include the GAP Bond Manager when building the Host Test application as peripheral. This is also covered in https://sir.ext.ti.com/jira/browse/EXT_EP-10234.
  3. Certain Vendor-Specific HCI Commands are no longer available, e.g. GAP Make Discoverable (0xFE06), GAP Update Advertising Data (0xFE07).

 

For the above reasons we've gone the route of compiling the stack only for peripheral and we're looking at how to modify the application on our main MCU to do without GAP bonding, as well as started to investigate what HCI commands we need to update on the main MCU side.

 

However, we're looking to change as little as possible, and we've discovered that earlier versions of the SDK (version 1.40.00.45) have these 3 points covered. Host Test can be configured both as central and peripheral, with GAP Bond Manager included and it has support for the HCI commands that we use today.

So that leaves us with the question if it's possible to use this early version of the SDK and still reference a QDID from you for Bluetooth SIG Qualification? The TI BLE5-Stack 1.00.01.45 Release Notes reads that the stack is fully qualified, though I understand if this could no longer be the case.

Regards,

/ Wolfgang

  • 0
    Prodigy 30 points

    Hello,

    I am the customer who contacted Wolfgang. Taking a more thorough read of How to Certify Your Bluetooth Product I believe erratum 11838 makes any SDK prior to 4.10.00.10 obsolete. Would that be correct?

    Unrelated to CC2640R2, but while looking at that erratum I see that the final paragraph for users of CC26x0/CC13x0 reads: Therefore, no extra test evidences or test reports for erratum 10734 are required. Is that a typo from erratum 10734 above, should it be erratum 11838?

    / Kristoffer

  • 0 in reply to Kristoffer Sliwinski
    TI__Guru** 101570 points

    Hello Kristoffer and Wolfgang,

    Thank you for reaching out and providing all these details.

    Before answering your questions, I would like to make sure I highlight the possibility to use the cost optimized CC2340R5 or CC2340R2 device for the use case you have described. The devices I have mentioned support the host_test example in multi-role mode with quite similar APIs as for the host_test example in the CC2640R2 ble5stack. As you are already going through a migration process, I believe it could make sense to consider these devices.

    Note: the rest of my answer applies to the CC2640R2 device.

    Kristoffer Sliwinski said:
    Taking a more thorough read of How to Certify Your Bluetooth Product I believe erratum 11838 makes any SDK prior to 4.10.00.10 obsolete. Would that be correct?

    This is true assuming you want to apply for Bluetooth qualification.
    In all the cases, I would recommend to be extremely careful when looking at going to production with a 7+ year-old SDK.

    Kristoffer Sliwinski said:
    Unrelated to CC2640R2, but while looking at that erratum I see that the final paragraph for users of CC26x0/CC13x0 reads: Therefore, no extra test evidences or test reports for erratum 10734 are required. Is that a typo from erratum 10734 above, should it be erratum 11838?

    Good catch, thank you for reporting it. This is a typo. I have fixed it, and should be appeared online after the next release (1 month or so).

    I hope this will help,

    Best regards,

  • 0 in reply to Clément
    TI__Guru** 101570 points

    Hi,

    Closing this thread due to inactivity.

    If further support is required, please open a new thread as I am about to be out of the office for an extended period.

    Thank you for your comprehension.

    Best regards,

  • 0 in reply to Clément
    Prodigy 30 points

    Hi Clément,

    Sorry for the inactivity, this was submitted before I left for holidays.

    We considered the CC2340R5, but decided to go for CC2640R2 in the end. I believe the reason for this was the ESD rating.
    Anyway, I think we have the answers to our questions, so this can be marked as solved/closed. Thank you!


    Best regards,
    Kristoffer