• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 57 subscribers
  • Views 211 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.

CC1352P: ZCD_NV_GROUP_TABLE cannot be read and written from SDK 5_10_00_48

albgarc2014
Genius 3215 points
Part Number: CC1352P
Other Parts Discussed in Thread: SYSCONFIG, Z-STACK

Hello TI,

We have developed our software to clone the network coordinator. The software works perfectly up to SDK version 4_40_04_04; but in later versions the ZCD_NV_GROUP_TABLE cannot be read and written.

I have tried with the TI application: TI_Zigbee_Network_Properties_Cloning_Tool and I get the same result.

I read in the SDK release 5_10_00_48 that the ZCL Group table NV implementation was optimized.

My questions:

1-) Why can't I read or write the ZCD_NV_GROUP_TABLE?

2-) The ZCD_NV_GROUP_TABLE was removed from SDK version 5_10_00_48?

3-) The ZCD_NV_GROUP_TABLE was replaced by another table?

4-) How should I implement (or where can I find the information) the new way to read or write the ZCD_NV_GROUP_TABLE or its replacement?

Please if you consider that I need additional information to my questions, please accept all suggestions.

Thank you very much.

Best regards!

  • +1
    Guru 735455 points

    According to zcomdef.h, ZCD_NV_LEGACY_GROUP_TABLE(0x0042) is deprecated and replaced by  ZCD_NV_EX_GROUP_TABLE (0x0008).

  • +1
    TI__Guru**** 202046 points

    Hello albgarc,

    YiKai is correct, ZCD_NV_GROUP_TABLE has been deprecated, renamed to ZCD_NV_LEGACY_GROUP_TABLE, and replaced with ZCD_NV_EX_GROUP_TABLE to allow for actual table entries instead of one large NV item.  You can modify config_nv_regions.txt accordingly for NV Region ZCD_NV_EX_GROUP_TABLE, Item ID 0x0008, Sys ID 0x01, Sub ID 0x0000, Entries 16 (default Group Table Size/APS_MAX_GROUPS from SysConfig).

    Regards,
    Ryan

  • 0 in reply to YiKai Chen
    Genius 3215 points

    Sincerely, Thank you very much. 

  • 0 in reply to Ryan Brown1
    Genius 3215 points

    Sincerely, Thank you very much. 

  • 0 in reply to Ryan Brown1
    Expert 1310 points

    Hi Ryan,

    If we backup a controller with a 4.x firmware and then need to restore to a controller with 5.x firmware, will it be sufficient to write the contents of ZCD_NV_GROUP_TABLE into ZCD_NV_LEGACY_GROUP_TABLE and the application will automatically transform the data into ZCD_NV_EX_GROUP_TABLE? Or will the old group data always remain in the legacy table and so, for future 5.x to 5.x updates, we will always need to backup the new as well as the legacy table?

    Regards
    Peter

  • +1 in reply to Peter Hoyer
    Guru 735455 points

    In general coordinator application, you usually won’t add coordinator into any specific group, which means you can consider if it is necessary to backup group table.

  • 0 in reply to YiKai Chen
    Expert 1310 points

    Thank you YK. So said this, if no groups are defined in case of the module being a coordinator, it could also be sufficient just leaving out that table?

  • +1 in reply to Peter Hoyer
    Guru 735455 points

    Yes, that’s correct.

  • 0 in reply to YiKai Chen
    Expert 1310 points

    One more question. from your point of view, which of the following tables are actually needed for a coordinator backup/restore?

    ZCD_NV_PANID
    ZCD_NV_EXTADDR
    ZCD_NV_EXTENDED_PAN_ID
    ZCD_NV_BDBNODEISONANETWORK
    ZCD_NV_NIB
    ZCD_NV_NWK_ACTIVE_KEY_INFO
    ZCD_NV_NWK_ALTERN_KEY_INFO
    ZCD_NV_EX_NWK_SEC_MATERIAL_TABLE
    ZCD_NV_EX_TCLK_TABLE
    ZCD_NV_GROUP_TABLE (already excluded)

    Reason is that we are going crazy with a backup/restore problem where the process "mostly" works but in some cases the Z-Stack Linux gateway will connect but receive empty data (MAC and Pan) or there will be some minutes of SRSP errors until it finally connects. It happens with our own tool as well as with TI's Python scripts.

    We have not been able to find the reason through debugging yet and reducing the amount of restored data to a necessary minimum will at least exclude some potential sources of error.

  • +1 in reply to Peter Hoyer
    Guru 735455 points

    other than ZCD_NV_GROUP_TABLE, you should keep those left for backhand restore. In our own implementation of back and restore mechanism, I don’t see failure as yours.

  • +1 in reply to Peter Hoyer
    TI__Guru**** 202046 points

    Hi Peter,

    You can do as YK recommends.  We also have a note in the Z-Stack User's Guide -> Non-Volatile Memory Items section for this use case:  "If using APS groups and upgrading a project from Z-Stack 4.4.0 or earlier to 5.1.0 or later using the OTA method, ZSTACK_NVOCMP_MIGRATION must be defined in the 5.1.0+ project to account for a new feature in which each group table has been separated into its own NV ID subset."  This also applies to ZC backups.

    Regards,
    Ryan