• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 709 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.

ZCL Scenes management issue (store all scene entries in RAM runs out of RAM)

whatcall
Intellectual 305 points
Other Parts Discussed in Thread: CC2530, Z-STACK, CC2538, CC2538-SW

After some digging in this MAX_GROUPS issue , we found the root cause may be the scenes information management strategy in current Z-stack. As we know, CC2530 has only 8KB RAM, a typical 4 endpoints HA sample light will use more than 7KB RAM. We try to support 64 groups and 64 scenes for all 4 endpoints, but the stack stores scenes information in RAM and read/write as a whole NV item when add/remove scene command received (see zcl_general.c  for reference). This means 64 scene record will eat at least  64*46bytes =  2944bytes RAM when reaching the max capacity. So it is not supprised that when add some more scenes will cause the unresponsive issue. I also have doubt about the group information storage method. Although I haven't found the exact code (because aps_groups.c is not open source) related with groups management, the test result shows more groups will cause more RAM usage after it loads them from NV ROM. We are considering mod the scenes NV access interface for more efficient RAM usage to solve this issue.Before that, I want to know if anybody has ever encountered it and may have an existed solution.

  • 0
    Guru 735685 points

    64 groups is really too large for CC2530. If this is must for your project, you might want to have a try on CC2538(http://www.ti.com/tool/cc2538-sw), which is based on cortex-M3.

  • 0 in reply to YiKai Chen
    Intellectual 305 points

    Hi Yikai,

    The key point is Z-stack could do better to manage scenes(maybe also group names info)  in NV ROM. It may improve the RAM usage performance by not reading all scenes into RAM. Instead, read a scene when only it is required. We can not assume one radio runs only a single endpoint application. I mean, that's too simple for real project. Considering a typical 4 ep project like we use, each ep supports 16 groups will require the whole radio to support 64 groups.

    CC2538 is a good choice for new design, but we cannot afford spending a lot of time to redesign the whole HW/FW stuff. Anyway, thanks for your suggestion. We are planning to rewrite the scenes accessing functions for CC2530 to solve this issue.

  • 0 in reply to whatcall
    Guru 735685 points

    Full agree with you --"The key point is Z-stack could do better to manage scenes(maybe also group names info)  in NV ROM. It may improve the RAM usage performance by not reading all scenes into RAM. Instead, read a scene when only it is required." It can be solved if you can rewrite the scenes/groups accessing functions.