Compiler/LPSTK-CC1352R: LPSTK-CC1352R

Hi Jo,

You seem to be on the right track, you just seem to have had a minor hick-up on the kernel part of the merging.

Consider both projects stand-alone. Each project depend on TI-RTOS and thus generate a kernel using the XDC tools and the .cfg file. (In the EasyLink case there is likely an external project for TI-RTOS while the BLE project does not split like this). When the kernel is build, the packets you list above is generated which is then later linked with the application.

When you merge two TI-RTOS projects you don't merge the TI-RTOS generated files as well. Typically you never move files found in the "Debug" folder as these are generated files. A project should/need to only have one .cfg file which is the same as saying that it only contain one TI-RTOS setup. This means that you should choose one set of TI-RTOS files (in this case, i recommend going with the BLE) and make sure that this .cfg file used to generate these aligns with that of the other project.

Best regards,

Max

Hi Max,

Thank you for your quick response. I get it! Both projects configure TI_RTOS thanks to their *.cfg file

So I compared both *.cfg file and below are the main difference:

/* ================ Program configuration ================ */
/*
* Program.stack must be set to 0 to allow the setting
* of the system stack size to be determined in the example's
* linker command file.
*/
Program.stack = 0; //for <rfEasyLinkTx>

Program.stack = 1024; //for <BLE simplePerihperal>

/*
* Minimize exit handler array in the System module. The System module includes
* an array of functions that are registered with System_atexit() which is
* called by System_exit(). The default value is 8.
*/
System.maxAtexitHandlers = 2; // for <rfEasyLinkTx>

System.maxAtexitHandlers = 0; //for <BLE simplePerihperal>
/*
* If Task.enableIdleTask is set to true, this option sets the idle task's
* stack size.
*
* Reducing the idle stack size yields greater memory savings.
*/
Task.idleTaskStackSize = 512;  //for <rfEasyLinkTx>

Task.idleTaskStackSize = 768; //for <BLE simplePerihperal>

/* ================ Mailbox configuration ================ */
var Mailbox = xdc.useModule('ti.sysbios.knl.Mailbox'); //for <rfEasyLinkTx>
no mailbox //for <BLE simplePeripheral>

I tried different *.cfg combination and make sure to use similar *syscfg (enable Sub-1GHz in the RFDesign) file but for a spurious reason, in the BLE project, my RF module hangs when calling the function:

RF_EventMask RF_runCmd(RF_Handle h, RF_Op* pOp, RF_Priority ePri, RF_Callback pCb, RF_EventMask bmEvent)

in the rfEasyLinkTx, this function is defined in C:\ti\simplelink_cc13x2_26x2_sdk_4_10_00_78\source\ti\drivers\rf\RFCC26X2_multiMode.c 

whereas in the BLE simple peripheral this function is implemented within this library:

-l$(SIMPLELINK_CC13X2_26X2_SDK_INSTALL_DIR)/source/ti/drivers/rf/lib/rf_multiMode_cc13x2.aem4f

Questions:

1. Does this library contain a specific RF_*  implementation which could lead to an incompatibility with the sub-1GHz?
2. For the BLE project, is there any limitation to build C:\ti\simplelink_cc13x2_26x2_sdk_4_10_00_78\source\ti\drivers\rf\RFCC26X2_multiMode.c instead of tlink with he library rf_multiMode_cc13x2.aem4f?
3. If yes, how to rebuild/configure this library in order to be compatible with the sub-1GHz interface?
4. Finally, where could I get precise information related to this build process?

Sincerely

In the BLE simplePeripheral project, I removed the dependency with the library rf_multiMode_cc13x2.aem4f, and then build the source file C:\ti\simplelink_cc13x2_26x2_sdk_4_10_00_78\source\ti\drivers\rf\RFCC26X2_multiMode.c (like within the rfEasyLinkTx)

The interesting things is that the linker complains that some function are not implemented:

  symbol                        in file                          
 ---------                  ----------------                     
 NOROM_RFCAnaDivTxOverride  ./obj/debug/RFCC26X2_multiMode.o     
 NOROM_RFCCpeIntGetAndClear ./obj/debug/RFCC26X2_multiMode.o     
 NOROM_RFCCpePatchReset     ./obj/debug/RFCC26X2_multiMode.o     
 NOROM_RFCDoorbellSendTo    ./obj/debug/RFCC26X2_multiMode.o     
 NOROM_RFCHwIntGetAndClear  ./obj/debug/RFCC26X2_multiMode.o     
 NOROM_RFCOverrideSearch    ./obj/debug/RFCC26X2_multiMode.o     
 NOROM_RFCOverrideUpdate    ./obj/debug/RFCC26X2_multiMode.o     
 NOROM_RFCSynthPowerDown    ./obj/debug/RFCC26X2_multiMode.o     
 rf_patch_cpe_bt5           ./obj/debug/ti_radio_config.o        
 rf_patch_mce_iqdump        ./app/../lib/libmioty_1.0.0.a<rfDl.o>

Basically, the BLE simple peripheral uses a dedicated and patched RFCC26X2_multiMode.c module which prevents me to add/use sub-1GHz functionality.

1- Please advise how to merge both projects if TI developer patched some SDK common file/function within the BLE simple peripheral?

2- Is there any reference/documentation which could help me to understand this opaque build process?

Sincerely,

Hi,

Thank you for your response.

"As your end goal seems to be Easylink + BLE using DMM I would actually recommend that you take the "dmm_wsnnode_ble_sp_app" example and simply replace the EasyLink and BLE application files in this project as it means you do not need to manually setup it all from the beginning. If you prefer to stick with merging yourself, this example should still serve as an example on how the project settings need to be setup in your case."

My initial objective is just to received BLE write request/command in order to configure the device and adds Over The Air Update.

Basically, when the BLE is ON, Sub-1GHz is OFF.

When the Sub-1Gh is ON, the BLE is OFF (a button pressed will start the BLE advertising and shutdown the Sub-1GHz Tx)

So BLE and Sub-1GHz are not running concurrently but sequentially!

"I would recommend to always go with the "BLE" value when you have to choose (in terms of stack sizes etc)."

Actually I probably  narrow done the issue

1. I kept the BLE *.cfg and adds the mailbox support required for the Sub-1Ghz application.
2. Within the BLE simple peripheral example, I added the <RfEasyTx> source file.
3. Each protocol runs on its own thread.
4. For testing purpose, I don't initialize the BLE application and stack (no ICall_createRemoteTasks call)
5. sub-1GHz can transmit without any issue!
6. Then in the main.c, I initialized the BLE5-Stack by calling ICall_createRemoteTasks
7. Sub-1GHz does not transmit anymore.... the system hangs on the RF_runCmd
8. I comment ICall_createRemoteTasks
9. sub-1GHz can transmit without any issue

So from my basic understanding, as soon as the thread related to the BLE5-stack is initialized, I can't use the RF_runCmd API.

1. Is there any restriction?
2. Is the DMM interface required even if we don't plan to use both stacks simultaneously?

Sincerely

Hi M-W,

I made some progress by enabling the DMM, and editing the radio policy.

However, how could I run an immediate command like CMD_GET_FW_INFO with the Rf_scheduler (when BLE stack is already initialized)?

Am I doing something wrong?

    RF_open() 

    rfc_CMD_GET_FW_INFO_t cmdInfo;

    cmdInfo.commandNo = CMD_GET_FW_INFO;

    RF_ScheduleCmdParams sched_params;
    RF_ScheduleCmdParams_init(&sched_params);

    sched_params.endTime = 0;
    sched_params.allowDelay = RF_AllowDelayAny;


    RF_CmdHandle  cmdHdl = RF_scheduleCmd(handle, (RF_Op*)&cmdInfo, &sched_params, 0, 0);

    Rf_close()

Sincerely,

Hi Jo,

Have you tried the "run immediate" API?