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.

LAUNCHXL-CC1352P: How to enable/disable High PA in sysconfig

Part Number: LAUNCHXL-CC1352P
Other Parts Discussed in Thread: SYSCONFIG, CC1352P, , , LAUNCHXL-CC1352R1, CC1352R

Hi,

  Hobbyist here. I'm trying to disable High PA in my simple_peripheral project by doing the following changes on Sysconfig:

1 - Tab "Software->BLE->Radio->BLE Radio Configuration": Unmarking the option "High PA" and choosing "5" in the "Tx Power (dBm)" holder.

2 - Tab "Software->RF Design": Choosing "None" in the "Assing High PA to Frequency Band".

  When trying to build I get the following errors in the file "ble_user_config.c":

1 - identifier "pOverrides_bleTx20" is undefined ble_user_config.c /simple_peripheral_CC13X2P_2_LAUNCHXL_tirtos_ccs/iCallBLE line 365 C/C++ Problem

2 - identifier "pOverrides_bleTxStd" is undefined ble_user_config.c /simple_peripheral_CC13X2P_2_LAUNCHXL_tirtos_ccs/iCallBLE line 364 C/C++ Problem

ble_user_config.c is not automatically generated by sysconfig, so I guess I probably missing one step to disable "High PA".

One interesting point is that I get the following message on the sysconfig tab "Software->BLE->Radio->BLE Radio Configuration":  "The BLE module is not using RF_Mode from ti_radio_config.c".

I'm using cc13x2_26x2_sdk_5_10_00_48 (I know is outdated by it used to work when I was doing some testing one and a half year ago).

 

Thanks in advance!

  • Hi Elias,

    FYI, it actually happens in SDK 6.20 as well. We will check that out.

    Regards,

    Arthur

  • Hi again Elias,

    Are you ever gonna use the PA in your application?
    The workaround here is to actually import the "simple_peripheral"  for the CC13X2P_1_LAUNCHXL Launchpad, but we will try to find the cause for that behavior.

    Regards,

    Arthur

  • Arthur, Hi!

      I plan to use it on the future, but I can backup the current one that is working with "High PA" enabled. I'll test tomorrow and let you know the outcome.

      My idea is to have edge BLE devices using normal PA (5 dBM) to communicate with Smartphones and using "High PA" in the BLE Mesh. Can this be configured at run-time? Or I need to choose one of them and stick with it permanently (only changing it during config-time) ?

    Best Regards,

  • Hi Elias,

    It seems like this did not help you. Do you have more details you are willing to share so that we can help you?

    Regards,

    Arthur

  • Hi, Arthur!

      Expend the whole night yesterday trying to make it work. All of the workarounds provided didn't work, check them below:

    1 - Import the "simple_peripheral_CC1352P1_LAUNCHXL_tirtos7_ticlang" copied ble_user_config.c to the "simple_peripheral_CC1352P_2_LAUNCHXL_tirtos7_ticlang"; still the same issue happens.

    2 - Tried to use "Custom Board" option, but there are a lot of parameters to set which using common values for the operation; Same issue is still present and new ones are raised.

      Is there a way to disable sysconfig tool to autogenerate the ti_radio_config.c? I am thinking about using snippets of code from the one generate for "High PA" for the normal PA.

      Also from the other thread, I do understand that there is a way to change Tx power at runtime, but selecting/deselecting "High PA" doesn't seem to be an option? Can you confirm that?

    Best Regards,

    Elias

  • Hi Elias,

    That is strange, for the workaround 2, looking at the power consumption (0dBm vs 20dBm) with the instruction I have sent you, it seems to work. I have been using the 6.20 SDK, which is probably explains why. I will try on 5.10.

    As of your Sysconfig question, here is how you would do it:

    1. First, copy the generated ti_radio_config.c/.h if you have to save it.
    2. Click on the brackets button in Sysconfig, at the top-right of the window.
    3. Disable generation of the files by un-checking the radio buttons.

    Regards,

    Arthur

  • Hi, Arthur!

      Actually I've used the 6.20 SDK when I tried to use "Custom Board" setting for the workaround 1.

      I've tried to disable autogenerate, but when I try to build the CCS deletes the files that aren't select, so a lot of errors are raised due to the lack of ti_radio_config.h .

      I've officially given up of trying to use this board with the normal PA, perhaps it was intended to be this way.

    Best Regards,

    Elias

      

  • Hi Elias,

    If you look at my previous instructions, the first step was to copy both ti_radio_config.h and ti_radio_config.c to the root of your project, precisely to prevent those errors. Could you give it one more try?

    Regards,

    Arthur

  • Hi, Arthur!

    Look in the picture, the same errors are being raised.

    1 - I copied both ti_radio_config.h and .c from "simple_peripheral_CC1352P1_LAUNCHXL_tirtos7_ticlang" project and paste them into the root of project "simple_peripheral_CC1352P_2_LAUNCHXL_tirtos7_ticlang".

    2 - Disabled autogeneration of those files.

    3 - Tried to build once again.

    Regards,

  • Hi Elias,

    Indeed, it happens because it is the problem this E2E post is about. I realized the instructions I sent you previously where wrong (in regard to the custom board setting).

    Again, you have to use switch the project so that it uses a custom board, in SysConfig. But this time, use "LAUNCHXL-CC1352P1". At this point, I assume that the error you encounter is " you_must_implement_rfDriverCallbackAntennaSwitching_see_generated_ti_drivers_config_c_in_debug_folder_or_sysconfig_preview ./syscfg/ti_drivers_config.o".

    In order to fix that error, copy-paste the following code in your simple_peripheral.c (copied from original simple_peripheral project's ti_driver_config.c) :

    /*
     * ======== rfDriverCallbackAntennaSwitching ========
     * Sets up the antenna switch depending on the current PHY configuration.
     *
     * Truth table:
     *
     * Path       DIO28 DIO29 DIO30
     * ========== ===== ===== ===== 
     * Off        0     0     0
     * 2.4 GHZ    1     0     0
     * HIGH PA    0     1     0
     * SUB1 GHZ   0     0     1
     */
    void rfDriverCallbackAntennaSwitching(RF_Handle client, RF_GlobalEvent events, void *arg)
    {
    
        if (events & RF_GlobalEventRadioSetup) {
            bool    sub1GHz   = false;
            uint8_t loDivider = 0;
    
            /* Switch off all paths. */
            GPIO_write(CONFIG_RF_24GHZ, 0);
            GPIO_write(CONFIG_RF_HIGH_PA, 0);
            GPIO_write(CONFIG_RF_SUB1GHZ, 0);
    
            /* Decode the current PA configuration. */
            RF_TxPowerTable_PAType paType = (RF_TxPowerTable_PAType)RF_getTxPower(client).paType;
    
            /* Decode the generic argument as a setup command. */
            RF_RadioSetup* setupCommand = (RF_RadioSetup*)arg;
    
            switch (setupCommand->common.commandNo) {
                case (CMD_RADIO_SETUP):
                case (CMD_BLE5_RADIO_SETUP):
                        loDivider = RF_LODIVIDER_MASK & setupCommand->common.loDivider;
    
                        /* Sub-1GHz front-end. */
                        if (loDivider != 0) {
                            sub1GHz = true;
                        }
                        break;
                case (CMD_PROP_RADIO_DIV_SETUP):
                        loDivider = RF_LODIVIDER_MASK & setupCommand->prop_div.loDivider;
    
                        /* Sub-1GHz front-end. */
                        if (loDivider != 0) {
                            sub1GHz = true;
                        }
                        break;
                default:break;
            }
    
            if (sub1GHz) {
                /* Sub-1 GHz */
                if (paType == RF_TxPowerTable_HighPA) {
                    /* PA enable --> HIGH PA
                     * LNA enable --> Sub-1 GHz
                     */
                    GPIO_setMux(CONFIG_RF_24GHZ, IOC_PORT_GPIO);
                    /* Note: RFC_GPO3 is a work-around because the RFC_GPO1 (PA enable signal) is sometimes not
                             de-asserted on CC1352 Rev A. */
                    GPIO_setMux(CONFIG_RF_HIGH_PA, IOC_PORT_RFC_GPO3);
                    GPIO_setMux(CONFIG_RF_SUB1GHZ, IOC_PORT_RFC_GPO0);
                } else {
                    /* RF core active --> Sub-1 GHz */
                    GPIO_setMux(CONFIG_RF_24GHZ, IOC_PORT_GPIO);
                    GPIO_setMux(CONFIG_RF_HIGH_PA, IOC_PORT_GPIO);
                    GPIO_setMux(CONFIG_RF_SUB1GHZ, IOC_PORT_GPIO);
                    GPIO_write(CONFIG_RF_SUB1GHZ, 1);
                }
            } else {
                /* 2.4 GHz */
                if (paType == RF_TxPowerTable_HighPA)
                {
                    /* PA enable --> HIGH PA
                     * LNA enable --> 2.4 GHz
                     */
                    GPIO_setMux(CONFIG_RF_24GHZ, IOC_PORT_RFC_GPO0);
                    /* Note: RFC_GPO3 is a work-around because the RFC_GPO1 (PA enable signal) is sometimes not
                             de-asserted on CC1352 Rev A. */
                    GPIO_setMux(CONFIG_RF_HIGH_PA, IOC_PORT_RFC_GPO3);
                    GPIO_setMux(CONFIG_RF_SUB1GHZ, IOC_PORT_GPIO);
                } else {
                    /* RF core active --> 2.4 GHz */
                    GPIO_setMux(CONFIG_RF_24GHZ, IOC_PORT_GPIO);
                    GPIO_setMux(CONFIG_RF_HIGH_PA, IOC_PORT_GPIO);
                    GPIO_setMux(CONFIG_RF_SUB1GHZ, IOC_PORT_GPIO);
                    GPIO_write(CONFIG_RF_24GHZ, 1);
                }
            }
        }
        else if (events & RF_GlobalEventRadioPowerDown) {
            /* Switch off all paths. */
            GPIO_write(CONFIG_RF_24GHZ, 0);
            GPIO_write(CONFIG_RF_HIGH_PA, 0);
            GPIO_write(CONFIG_RF_SUB1GHZ, 0);
    
            /* Reset the IO multiplexer to GPIO functionality */
            GPIO_setMux(CONFIG_RF_24GHZ, IOC_PORT_GPIO);
            GPIO_setMux(CONFIG_RF_HIGH_PA, IOC_PORT_GPIO);
            GPIO_setMux(CONFIG_RF_SUB1GHZ, IOC_PORT_GPIO);
        }
    }


    Please clean the project between every step.

    I have attached the project here, for the 6.20 SDK: sp_no_PA_620.zip

    Regards,

    Arthur

  • Hi, Arthur!

      Will it work when I flash this project to LAUNCHXL-CC1352P ? I don't have the LAUNCHXL-CC1352P1 board. I mean, not only compile/build, but will the features work as well?

    Regards,

    Elias

  • Hi Elias,

    It will work, but as the RF matching networks are different between the LAUNCHXL boards, you are not going to get the optimum range/current consumption. As it is a hobby project, this should be fine.

    Is there a reason for not picking the LAUNCHXL-CC1352R1, other than just having the LAUNCHXL-CC1352P2  laying around?

    Regards,

    Arthur

  • Hi, Arthur!

      It worked, but the "simple_peripheral_CC1352P1_LAUNCHXL_tirtos7_ticlang" project was working with the HIGH PA option disabled before I performed the changes you asked (Custom board and adding code snippet to simple_peripheral.c). So what is the difference between these two right now?

      Regarding the board, it seemed to me the best pick at the time since I wanted to switch Tx power settings for my personal project. What is the main difference between them?

    Best Regards,

    Elias

  • Hi Elias,

    The difference is that now, with the custom board, you have freedom of choosing RF settings, and the High-PA will be enabled depending on what settings you choosed (here with CC1352P-2 settings, and High-PA assigned to the 2.4GHz band):

    Bear in mind that you do have to leave the High-PA assigned to the 2.4 GHz for it to work. That is what escaped us in the first place, and caused the issue.

    The CC1352R and the CC1352P are the same chip, but the CC1352P integrates a RF Power amplifier, as we have seen. The CC1352R can output +14dBm in the Sub-1 GHz frequency band, and 5dBm in the 2.4 GHz.

    Regards,

    Arthur