• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 361 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2652P7: Thread firmware missing capabilities required by esp32 OTBR

Tim Lunn
Prodigy 100 points
Part Number: CC2652P7
Other Parts Discussed in Thread: CC2652P

Tool/software:

I am trying to integrate OTBR running on ESP32 with Thread firmware on CC2652P/P7/P10. Thread firmware is based off the 1.3 certified release from last year.

This OTBR implementation seems to require a few capabilities that are missing from the TI firmware (that are not otherwise required from the ot-br-posix implementation)


E(672) OPENTHREAD:[C] P-RadioSpinel-: RCP is missing required capabilities: 
E(672) OPENTHREAD:[C] P-RadioSpinel-:     sleep-to-tx
E(672) OPENTHREAD:[C] P-RadioSpinel-:     rx-timing
E(682) OPENTHREAD:[C] P-RadioSpinel-:     rx-on-when-idle

The last one listed there is in fact optional (can be disabled with build flags) but the first 2 are required. Are there any plans to implement these capabilities? Has there been any further work on the Thread firmware since the last release, working on 1.4 release etc?


  • 0
    TI__Guru**** 218057 points

    Hi Tim,

    You are correct in that TI does not support the features that are listed, as they weren't required in the1.3 Openthread Border router release that TI validated against.  

    If you are rebuilding the OTBR on the ESP32, then the openthread commit you're using should be the same one used in the ot-ti v1.3 release. 

    The current target is to release Thread v1.4 support by the end of Q1 2025.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 100 points

    Hi Ryan,
        It is not that easy to build Espressif border router at a spefic commit. They seem to have implemented the border router as a closed source static library and its not clear how much of the upstream code they use directly. They also only just introduced TREL support recently which we require for our purposes.

    It appears that the `rx-timing` capability is actually optional, it is used to indicated receive timing is handle by the radio, if its missing it should be handled in software (atleast it is handled in posix otbr container). I suppose they didnt implement the software timing as their RCP firmware supports rx-timing.

    For `rx-on-when-idle` seems this is made mandatory, not sure if that is in 1.4 or a later release though.

    We be happy to test out 1.4 builds once your closer to having something ready to release.

    - Tim