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.

Porting ZRC 2.0 profile with network processor running Remo-TI 1.3.1 based network image.

Other Parts Discussed in Thread: REMOTI

We are working on porting ZRC2.0 profile porting in below configuration.

                           TI Chip – CC2534

                            TI chip firmware - RNP-NWK-CC2534F64_SPI_v1_3_1_1943_FREQTUNE0x09.bin   (network Image, with no profile)

                            Host/Application Processor -  ZRC2.0/GDP profile + ZRC2.0 app                                                                                             (ZRC/GDP code is pulled from RemoTi-1.4 source code)

  We have couple of questions on this effort.

  1. Porting ZRC 2.0 profile with network processor running Remo-TI 1.3.1 based network image.

   On this configuration, we are able to initialize TI chip, and get RTI_InitCnf(), and also able to set and get network parameters through RCN API.  Once ZRC app enable pairing by calling RTI_AllowBind(), the same request is passed to GDP layer (to set a flag). There is no RCN call flow (discovery/pair) to network processor.   With this scenario, when we initiate pairing procedure on a RF remote,  we don’t see any RCN notifications being passed from network processor through RCN_CbackEvent() to RTI layer (running on host processor)

This make us concerned, whether the network processor running firmware based on Remo-TI 1.3.1 stack , unconditionally forwards discovery requests or not. 

  1. Network Image based on RemoTI 1.4.x release

Can TI provides network image based on RemoTI-1.4, and maybe more suitable for our needs (porting ZRC2.0 on host side)?

  • Hi,

    Based on section 1.3 of "RemoTI API.pdf" (located in Documents/API, one version is also here), you can use either RTI or RCN APIs (but not both). So I would not expect that the host would receive RCN messages.

    Do you mean that you are not seeing the RTI_BIND_CNF after you send the RTI_BIND_REQ?

    Also, the post here implies that the CC2534 is a ROM device, so I would need to check with a colleague whether flashing a new image would be possible.

    Regards,
    Toby

  • Toby,

    Our approach has been to use RCN API’s only, and we are porting, RTI, GDP, ZRC layers to host and use RCN commands for communication. We have identified that, there was an error in setting the parameter (RCN_NIB_NWK_INDICATE_DISCOVERY_REQUESTS).  After correcting the error, we are able to receive discovery indication callbacks from network processor.   

        Now, our STB(host processor) is able to send discovery response, then it receives “pair indication” and STB sends “pair response”. However, the RF remote stops responding after that.  Any suggestions on what could have been going wrong here?

  • Thanks for the update and clarification.

    If I understand correctly, you have a setup like the following:
    - RC: host + RNP (CC2534)
    - STB: RF4CE capable device

    And a sequence like: 
    - RC --> STB, discovery request
    - RC <-- STB, discovery response
    - STB, pair indication
    - RC <-- STB, pair response
    - RC stops responding

    When the RC stops responding, do you mean that the RC does not respond to messages sent to it from STB?

    If possible, can you send a sniffer log of the process?

  •     We are working for STB with CC2534 chip in recipient mode.   Our system configuration is like below.

                                CC2534 – runs in network processor mode

                                 Linux Host -  runs RTI, GDP, ZRC layers.

                                 Linux host communicates with CC2534 through SPI

     

    Note:  We ported RTI, GDP, ZRC layers from Remo-TI-1.4.x platform to Linux host. We did this, as TI advised us that, CC2534F64 chip doesn’t have enough memory to run ZRC on chip itself.

     

    We are testing our STB in above configuration, with RF remotes.  We have optimized the host side code, and now, pairing process is able to cross binding, security and get into configuration stage. We are looking further and will revert back, if we need further support.