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.
We are using the simplelink_cc13xx_cc26xx_sdk_6_10_00_29 SDK.
Our CCS project is using the DMM with BLE and a proprietary sub-gig protocol.
We have been using the CC1352P7-1 development kit successfully, the PA is configured for the sub-gig band.
The RF switch PA control signal is (correctly) asserted on sub-gig band transmits.
We have spun our own hardware design based on the CC1352P7-1 development kit.
The difference in our design is the PA path is optimized for and will be used with the 2.4 band (for BLE).
I have been trying to remap the PA control signal to the 2.4 band (BLE) path in syscfg.
1. Under RF Stacks->Custom->Custom PHY Settings->PHY Properties->High PA changed to unselected.
2. Under RF Design->RF Design->Assign High PA To Frequency Band set to 2.4 GHz
3. Under BLE-> Radio Configure BLE Radio Settings->BLE Radio Configuration->High PA changed to selected.
4. syscfg remains setup for the LP_CC1352P7-1 board.
With these changes I can compile and successfully run, but when checking with a logic analyzer I never see the RF switch PA control signal become asserted.
Also, the power output of BLE transmissions is correspondingly low compared to the non-PA BLE TX path.
When debugging the code in RF_decodeOverridePointers() I see that
*pRegOverrideTxStd = radioSetup->ble5_pa.pRegOverrideTxStd;
*pRegOverrideTx20 = radioSetup->ble5_pa.pRegOverrideTx20;
are both assigned NULL pointers from the ble5_pa configuration.
Without these overrides configured the PA signal will not get asserted.
Clearly there are some changes required outside of syscfg to properly setup the PA override tables for BLE so that it can transmit on the PA path.
I have been trying to modify the syscfg scripting files but have not been successful.
This seems like a very simple configuration change so any help to get this working is appreciated.
Hi Jim,
Would the procedure described in that thread work for you?
Regards,
Arthur
Hi Arthur, I found that link yesterday and tried to follow the instructions but it was slightly different than my case and I was not able to make it work.
Hi Jim,
I will check to see whether we can adapt that procedure to your case. There are not that many differences between those two boards.
Regards,
Arthur
Hi Jim, it seems that issue is related to a bug in the SDK, which will be fixed eventually. However, here is a procedure that will allow you to enable the 2.4 Ghz High-Pa on your custom board.
Apply the content of that archive to your SDK installation.
SDK620_patch_cc1352P71_highPA.zip
This will add the possibility to use the LP_CC1352P7-2 settings to your custom board.
This is based on the simple_peripheral project.
Click on the top-right board menu, and click "Use custom board"
You can now select the following radio settings.
Changing the TX power on the advertisement sets allows us to see that the HighPA pin is finally getting asserted.
Let us know the results on your side,
Regards,
Arthur
Hi Arthur,
I patched the SDK, but in order to switch to the LP_CC1352P7-2 configuration I also had to create a source\ti\boards\.meta\LP_CC1352P7_2.syscfg.json file. I just copied the _1 file and made a few edits to map it to the -2.
Now I see the PA control signal functioning and the power output is considerably higher!
Thank you for your help.