• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 55 subscribers
  • Views 368 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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-CC1352R1: Integrating Easylink with Zigbee Coordinator example using DMM

Ahmad Saleem
Prodigy 40 points
Part Number: LAUNCHXL-CC1352R1
Other Parts Discussed in Thread: SYSCONFIG

I am using CC1352R1 and CCS Version: 10.1.1.00004 with SDK simplelink_cc13x2_26x2_sdk_4_40_00_44. I am trying to use a simple Zstack zigbee coordinator/router example as a DMM along with Easylink Rx/Tx. I have also consulted the following link for the integration: https://dev.ti.com/tirex/explore/node?node=AMu-cvNgpJsLYI.IMLUI.A__pTTHBmu__LATEST

One thing I found different in my case compared to all the given examples and the above link is that ICALL is used, whereas Zstack-only examples use OSALport instead as given in osal_port.c file. However, I am using Osalport rather than ICall here since both should be equivalent.

I have tried two options. One with using Easylink (rfEasylinkEchoRx/Tx examples) and Zigbee stack in sysconfig and another using Custom1 (rfEchoRx/Tx examples) and Zigbee stack. Now, I am able to get PropRF Tx to work that I have verified with SmartRF studio (with multiprotocol enabled in sysconfig under Easylink stack settings), but both of the above options give same issue when trying to receive a packet via Prop RF. I have tried a lot of debugging and came to know that Rx gets stuck after receiving the first packet. I have tried both RF_runSchedulecmd and RF_schedulecmd without avail. I have observed that PropRF works fine (even for hours) until Zigbee commissioning. As soon as Zigbee is commissioned between a router and a coordinator, Rx RF_schedulecmd gets stuck (RxDoneCB never gets called, hence semaphore is never released). 

After issuing each command, I have verified the status of each Tx, FS and Rx command. It gives status code of command ended normally.

Kindly, let me know what can be the cause of this issue as I have already spent ample amount of time sorting it out including changing the GPT priorities (DMM). 

  • 0
    TI__Guru**** 202256 points

    Hi Ahmad,

    What PHY does your EasyLink stack use?  This could help explain concurrency issues once the Zigbee radio is initialized if the DMM Scheduler is not set up properly.  In the SLA, ICall is only added for ICall_getRemoteTaskHandle.  The dmm_zc_switch_remote_display_app uses stackTaskGetTaskHndl in main.c and I recommend you do the same (I'd still expect OsalPort to be utilized in the Zigbee application files).  You can refer to this example and dmm_wsnnode_remote_display_app for Policy Manager and Scheduler suggestions alongside application change recommendations.  Can you provide your project for further investigation?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 40 points

    Hi Ryan,

    The Easylink uses 50 kbps, 25 kHz Deviation, 2-GFSK, 100 kHz RX Bandwidth that I have tried in non-Easylink example too. If DMM is not setup properly, shouldn't Tx also not be working?

    Yes, I have using stackTaskGetTaskHndl  to get the handles for both Easylink and Zigbee tasks. I have gone through the DMM examples too alongside to see the differences as you suggested.

  • 0 in reply to Ahmad Saleem
    TI__Guru**** 202256 points

    I agree that the DMM has been initialized properly if TX is working alongside Zigbee operation.  Are you able to send EasyLink packets with the Zigbee stack commissioned?  As the Zigbee Coordinator is an "always-on" node which must always be ready to receive and forward packets, this RF stack could be taking full priority and preempting EasyLink RX operation.  Could you share your Global Priority and Policy Tables?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 40 points

    Yes, I am able to send Easylink packets even after commissioning. TxDoneCB is called with success status as opposed to Rx where RxDoneCB never gets called. I have tried two nodes, one with Zigbee coordinator and proprf RX while another node with Zigbee router and Proprf Tx. Both have the same Rx issue. I have observed that Rx works as long as commissioning is blocked. I think after commissioning Zigbee might be consuming full radio time not allowing Rx command to proceed. The Tx command does not require to wait for packets as Rx command. This might make a difference between the two commands.

    You are right about the priority, I have tried to give highest priority (250) to Rx too without avail. 

  • 0 in reply to Ahmad Saleem
    TI__Guru**** 202256 points

    Have you tried changing the DMM_StackPNormal/DMM_StackPHigh of  DMM_ESL_Rx  to 250 or just DMM_StackPUrgent?  Do you ever switch application states to DMM_StackPUrgent in your Proprietary application?  Given that the Zigbee stack will prioritize RX activity, you could force Proprietary reception by pausing the Zigbee stack through the DMM Policy Table (SysConfig, which you may want to provide as well) for DMM_ESL_Rx activities.  At the moment, the Proprietary radio is still not outweighing Zigbee for the DMM scheduler.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 40 points

    I have tried changing DMM_StackPNormal to 250 because Easylink is using normal priorities only to issue commands. I have not found a suggestion in the relevant TI guides (including the link in my first message to integrate DMM into a non-DMM single stack example) to pause a stack while using BLE/Zigbee or BLE/PropRf. I have also tried adding another policy in DMM sysconfig with Zigbee pause while PropRF is in RxTx state but it does not work after commissioning as well.  

  • 0 in reply to Ahmad Saleem
    TI__Guru**** 202256 points

    In BLE + Zigbee examples, Zigbee is paused while BLE is performing an OAD update (DMMPOLICY_BLE_OAD Application State).  You could also try further increasing Custom 1 stack Weight or using Balanced Mode as both stacks expect to have "RX always on".  This specific use case has never been tested internally but if I have time next week then I will attempt to further investigate.  Do you mind sharing your project?

    Regards,
    Ryan