• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 18 subscribers
  • Views 718 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.

ZRC2.0 Support on CC2534

Maxime ATHEE
Prodigy 740 points

Hello team,

My customer would need presicion after exchange on below exchange on CC2534: 

TI feedback : 

The CC2534 was a custom part that we offered for select customers so it wasn’t normally accessible from our website.  It was a ROMable device that could only be used with pre-configured firmware from TI.  It does not support ZRC2.0.   However it can be used as a network layer only device in which case the host processor performs the higher layers and in that case could be used to implement ZRC2.0.

However the CC2533F96 does support ZRC2.0 via RemoTI-1.4.0.

Thanks so much for the info re CC2534 and support for ZRC2.0. We are continuing to explore options to support these Charters RF4CE remotes on our XX CC2534 based boxes. Can you provide additional feedback on these follow-up questions? 

1.      Is the RF4CE MSO profile actually implemented on the CC2534 or is part of it implemented on the Linux side?

2.      Does the CC2534 expose the network layer to the Linux side?

3.      Does TI already have a version of ZRC2.0 that runs on Linux?  If so, is it possible to use that instead of starting from scratch?  If not, what level of support would TI be available for?

Thanks in advance for your help,

  • 0
    TI__Mastermind 28140 points
    Hi,

    As far as I understand, RF4CE is deprecated. Please refer to a similar discussion: e2e.ti.com/.../736876

    With that said, perhaps this resource may be useful: github.com/.../RemoTI-Linux
    In this case, the CC2534 would be the network processor and interface with a Linux host.


    Regards,
    Toby
  • 0 in reply to Toby Pan
    TI__Prodigy 740 points

    Hi Toby,

    Could you please clarify each point requested by customer ? 

    It isn't clear from my side

    Thanks, Maxime

  • 0 in reply to Maxime ATHEE
    TI__Mastermind 28140 points
    I've reached out to the appropriate parties.
    Please expect a reply, at earliest, during the middle of next week.
  • 0 in reply to Toby Pan
    TI__Expert 6315 points

    Hi,

    The initial feedback from TI reference in the original post is correct.

    1. Yes, there exist a version of firmware for CC2534 which implements RF4CE MSO.

    2. Yes, there exist a version of firmware for CC2534 which expose RF4CE network layer API

    3. We only have a version of ZRC2.0 that communicates with an embedded implementation of ZRC2.0. If the ZRC2.0 profile is fully ported to Linux that would require some manual work. The APIs are however identical, so it should not be too difficult. No level of support beyond existing documentation can be provided.

    Checkout this repository for a host implementation for ZRC2.0, on top of ZRC2.0 profile. This works with RemoTI-1.4.0 on CC2533F96. The above mentioned port is required to use network layer APIs.

  • 0 in reply to Torbjorn Sorby
    Prodigy 50 points
    Internally we found that some other SW stacks running on the same HW have a firmware that implements ZRC1.1 (firmware version 1.3.2). Can TI confirm this?


    If you can confirm this, then we have some follow up questions:

    What are our options for adding the ZRC2.0-specific messaging on top of ZRC1.1? We need to support QuickSet, battery power status, and possibly OTA updates. OTA updates uses vendor-specific messages while the other 2 use standard ZRC2.0 messaging.
  • 0 in reply to Ed Bortoni
    TI__Expert 6315 points

    Hi,

    ZRC2.0 is primarily improvements regarding pairing. The concept of buttonless pairing, bonding and improved security.

    I'm not 100% sure, but simply formatting ZRC2.0 data could probably be accomplished with the older SDKs (and ZRC1.1). However, it wouldn't be compliant since both sides would have to "agree" to secretly support the data format. It could then sort of be viewed as a vendor specific extension of ZRC1.1 (while still using a profile ID < 0xC0)...