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.

CC1350: Moving design from CC1352R to CC1350

Part Number: CC1350
Other Parts Discussed in Thread: CC1312R, , CC1352R, LPSTK-CC1352R, CC1310

Hi,

This is Mario. We are currently adapting our design to the available stock of microcontrollers and we are forced to replace CC1352R as there is no stock. As the stock of CC1312R is also very limited, we decided to move to CC1350 (in fact, we only need sub-1 GHz, no BLE). We use the design files of LPSTK-CC1352R as reference. Our question is: what changes are required to be done in the layout in order to make the design work? We noted several possible changes:

1) The crystal needs to be changed for CC1350 to 24 MHz instead of 48 MHz (CC1352R).

2) Whereas CC1352R has 4 RF pins, CC1350 has only two pins. As we are not going to use BLE, could we just simply connect RF_N and RF_P pins to the input of the Balun Filter used at the LPSTK-CC1352R design? Leaving the BLE inputs unconnected

3) One more question: in case we used CC1312R, we do not need to change anything right? Well, just leaving unconnected the BLE inputs of the Balun Filter from the LPSTK-CC1352R design could be enough.

Best regards,

Mario

MCU071A_LPSTK-CC1352R_Schematic.pdfLAUNCHXL-CC1350EU_1_3_0_Schematics.pdf

  • If you want to use the CC1350 on sub 1 GHz only, use the CC1310 reference designs as a starting point. This migration guide: https://www.ti.com/lit/pdf/swra587 indicate what has to be changed from a CC13x0 to a CC13x2 based PCB. 

    The crystal needs to be changed for CC1350 to 24 MHz instead of 48 MHz (CC1352R).

    Correct.

    Since CC1352R is more expensive than CC1350/ CC1310 I assume that you needed to go to CC1352R in the first place. Will the application fit in a smaller flash memory?  

  • Dear TER,

    Thank you for your response. Finally, we are using CC1312R instead, because we can use the same firmware and it has same processor, SRAM,etc. than CC1352R. However, I am not sure about the RF part, I think we need to change the Balun Filter because the one used for CC1352R has the BLE input and if it is not connected maybe some issues related with the lack of symmetry of the ports could appear?

    We think the replacement is 0850BM14E0016 , so the idea is to replace the filter and then we will only need to connect its output to a DC coupling capacitor and the antenna. Could you please confirm if this is the way to go?

    I also read in some other posts that discrete option is better forr long range, is the difference really significant? We target long range applications.

    Thank you and best regards,

    Mario

  • Please check the IPC chapter in https://www.ti.com/lit/pdf/swra640 on which IPC you can use with which part. I would change the IPC to ensure that you use all ports. 

    Using an IPC will typically give slightly lower performance than a discrete design which will give lower range. The app note that describe the IPCs outline the performance and this can be compared with the datasheet numbers. https://www.ti.com/tool/RF-RANGE-ESTIMATOR could be used to calculate the estimated delta in range. If your existing design uses an IPC you can get slightly better performance on the CC1312R design if you move to discrete components, this depends if the current performance is good enough or not.   

  • Dear TER,

    Thank you. The current performance in terms of range is OK for us using the Balun filter with CC1352R. Then, we'll probably use the Balun filter option with CC1312R too.

    Attached below, a schematic of the modified RF circuit. Could you please confirm if this is a valid approach? Or do we need to add any extra component?

    Thank you and best regards,

    Mario

  • Looks ok. Seems like you have forgotten to change the name on symbol.