CC2652R7: Thread: RCP - SPINEL_STATUS_NOMEM

Hi Sen,

Can you please remind me what branch of the ot-ti repository you are using?  In reviewing the openthread Github repository, it appears that SPINEL_STATUS_NOMEM is the result of OT_ERROR_NO_BUFS which both indicate a lack of buffer space to accommodate the RCP commands.  If this is happening on both the CC2652R1 and CC2652R7 under the same conditions then this is likely not a cause of insufficient memory on the device as the CC2652R7 has near double the Flash and RAM as its CC2652R1, so more plausible is indeed a Thread configuration.  Here are a few ideas for you to try:

• SysConfig's UART2 module: increase the RX/TX Ring Buffer Size
• src/FreeRTOSConfig.h: increase the configTOTAL_HEAP_SIZE
• openthread repo: modify OPENTHREAD_CONFIG_MESSAGE_BUFFER_SIZE, OPENTHREAD_CONFIG_NUM_MESSAGE_BUFFERS, OPENTHREAD_CONFIG_DEFAULT_SED_BUFFER_SIZE, OPENTHREAD_CONFIG_MESSAGE_USE_HEAP_ENABLE, etc. (note: I'm not sure of the effect given that OPENTHREAD_CONFIG_HEAP_EXTERNAL_ENABLE is 1 in src/openthread-core-cc13xx_cc26xx-config.h)
• openthread/src/ore/config/mle.h: OPENTHREAD_CONFIG_MLE_MAX_CHILDREN (was OPENTHREAD_CONFIG_MAX_CHILDREN in older Thread versions)

I suspect that the last bullet point is the most relevant since the config-mle documentation implies that its default value is 10.  Still it would be good to know about the first two in case you need to change the CC2652RX heap size or UART buffers, and for openthread repo questions which could be non-platform-specific you could also consider engaging with the OpenThread community by posting to the Github issues space or discussions forum (i.e. the more perspectives the better!).

If you needed to go further and debug the RCP itself then this would require debugging a running target or otherwise using CCS to program the RCP in a debugger session with a target configuration file loaded.  This is feasible but we should exhaust other leads first, such as 

Regards,
Ryan

Thank you, Ryan,

We already have OPENTHREAD_CONFIG_MLE_MAX_CHILDREN = 64

Do we have any limitation to increase the following to 64 as well? It looks much better performance but still we some minor issues. 

/**

 * Number of extended addresses in @ref ext_src_match_data_t.

 */

#define PLATFORM_RADIO_EXTADD_SRC_MATCH_NUM 10 --> 64

/**

 * Number of short addresses in @ref short_src_match_data_t.

 */

#define PLATFORM_RADIO_SHORTADD_SRC_MATCH_NUM 10 --> 64

Thank you 

The limitation would be RAM which you have significantly more of on the CC2652R7 than the CC2652R1.  You can increase the configTOTAL_HEAP_SIZE if necessary.  If CONFIG_NVSINTERNAL region size needs to increase then this would require a modification of the command linker file as well.  I'm not sure whether any of these values are stored in NV memory at the moment.  It makes sense that you need to match or exceed short/extended addresses with the maximum allowable number of children.  What are the minor issues you are still facing?

Regards,
Ryan

Hi Ryan,

We have 32 sensors. Sometimes, 2–3 sensors age out and detach. (we set all the values to 64 - OPENTHREAD_CONFIG_MLE_MAX_CHILDREN PLATFORM_RADIO_EXTADD_SRC_MATCH_NUM, etc )

We are still investigating the issue but just adding some logs from BR (CC2652R).

2026-02-03 12:55:34 notice otbr-agent[4609]: 23:43:26.988 [N] MeshForwarder-: Failed to send IPv6 ICMP6 msg, len:108, chksum:4371, ecn:no, to:0x303e, sec:yes, error:NoAck, prio:low
2026-02-03 12:55:34 info otbr-agent[4609]: 23:43:26.988 [I] DataPollHandlr: Indirect tx to child 303e failed, attempt 4/4
2026-02-03 12:55:34 info otbr-agent[4609]: 23:43:26.988 [I] Mac-----------: Frame tx attempt 1/1 failed, error:NoAck, len:112, seqnum:198, type:Data, src:0x3000, dst:0x303e, sec:yes, ackreq:yes
2026-02-03 12:55:34 info otbr-agent[4609]: 23:43:26.978 [I] DataPollHandlr: Rx data poll, src:0x303e, qed_msgs:1, rss:-82, ack-fp:1

Hi Ryan,

We have 32 sensors. Sometimes, 2–3 sensors age out and detach. (we set all the values to 64 - OPENTHREAD_CONFIG_MLE_MAX_CHILDREN PLATFORM_RADIO_EXTADD_SRC_MATCH_NUM, etc )

We are still investigating the issue but just adding some logs from BR (CC2652R).

2026-02-03 12:55:34 notice otbr-agent[4609]: 23:43:26.988 [N] MeshForwarder-: Failed to send IPv6 ICMP6 msg, len:108, chksum:4371, ecn:no, to:0x303e, sec:yes, error:NoAck, prio:low
2026-02-03 12:55:34 info otbr-agent[4609]: 23:43:26.988 [I] DataPollHandlr: Indirect tx to child 303e failed, attempt 4/4
2026-02-03 12:55:34 info otbr-agent[4609]: 23:43:26.988 [I] Mac-----------: Frame tx attempt 1/1 failed, error:NoAck, len:112, seqnum:198, type:Data, src:0x3000, dst:0x303e, sec:yes, ackreq:yes
2026-02-03 12:55:34 info otbr-agent[4609]: 23:43:26.978 [I] DataPollHandlr: Rx data poll, src:0x303e, qed_msgs:1, rss:-82, ack-fp:1

Have you checked the child aging out parameters and confirmed that these sensors have been checking in within the timeout window?  Is there any pattern or logic to the sensors which are detaching?

Regards,
Ryan

Thanks, Ryan. The configuration and poll look good.

#define SED_POLL_PERIOD_MS 180000 // 3 minutes
#define SED_CHILD_TIMEOUT_SEC 900 // 15 minutes

We wanted to confirm whether setting up 64 SEDs, as discussed earlier, could lead to any memory-related issues.

We are currently investigating and will keep you posted.