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.

CC2652RB: CC2652RB wireless proprietary protocol

Part Number: CC2652RB
Other Parts Discussed in Thread: CC2650, CC2652R

Hello, we are migrating from a CC2650 based design to a new one, based on the CC2652RB. We made some of the porting on the CC2652RB LaunchPad and after that we designed the new pcb and we had all the involved components assembled into the new boards, including all the peripherals, in order to complete and verify the porting in the full working final board. Our system was designed to operate in two mutual exclusive ways: BLE and proprietary protocol. The BLE mode works fine and we concluded all the related activities. Some days ago we started the porting of the proprietary protocol to the new platform and we found, astounded, that syscfg does not support such mode for the RB variant despite also the last released data sheet (Rev. D - Feb 2021) and all related documents clearly state that this protocol was supported !!!

After this unbelievable surprise, we read numerous posts about this topic and we have seen that other people are in the same situation.

Do we have to redesign our PCB and rebuild all the boards ??? Who pays for that and the time waste ??? The system has very stringent space constraints and the RB variant would be a perfect solution.

How can we proceed ? Do you have planned to enable the proprietary protocol for the RB variant and/or do you have a beta release, maybe, of the SDK that allows for proprietary protocol that you can share?

Many thanks

  • Hi Giuseppe,

    I don't have a good answer for you yet, but I will ask the software organization if there's an update or anything we can do to help you. Let me respond to you shortly.

    Best,

    Nate

  • Hi Giuseppe,

    I've consulted with the team responsible internally, and unfortunately we don't support proprietary RF for this device yet. I don't yet have a timeline for when we will be able to support it. I'm sorry about the lost time and boards.

    You may be able to recover some time and cost though by developing the code with a CC2652R device, then porting the code over to a CC2652RB. You would take all the RF settings from CC2652R device, disable sysconfig, then change just the 48 MHz oscillator settings to match those for a CC2652RB device. This document covers the steps you'll need to take to migrate from CC2652R to CC2652RB. The devices are fundamentally the same, so it should work. But, you do put yourself at risk of reduced support because this is not a configuration we've characterized nor tested yet. 

    If you think this is unrecoverable, you can ask for returns/replacement parts at this link here.

    https://www.ti.com/support-quality/additional-information/customer-returns.html