CC2674P10: ZCD_NV_STARTUP_OPTION appears to be read-only on adapter bootup

Do you use ZTool to write ZCD_NV_STARTUP_OPTION?

Hello Andrew,

Can you further explain how you are trying to read and write the NV items in the ZNP project, and the behavior you observe of the response you receive?  Have you tried to debug the project to understand what is occurring in the code execution?

Monitor and Test API
SWRA671

Regards,
Ryan

We tested with Z-Tool using  SYS_OSAL_NV_WRITE_EXT to write ZCD_NV_STARTUP_OPTION and it fails with error code NV_OPER_ERROR (0x0a). We then tried NV_DELETE and NV_ITEM_INIT to recreate the item which succeeded. After which writes to ZCD_NV_STARTUP_OPTION started working. But after chip is reset it returns to the failure state.

We tried testing in Z-tool to rule out any issue with Zigbee2MQTT.

When trying that link it already fails at the first step:



Only if we delete and re-initialise ZCD_NV_STARTUP_OPTION item, can we write to it successfully. However it fails straight away again after the cc2674p10 is reset.

Just tested same project (apart from chip config) built on LP_CC2652R7 does not exhibit this issue. So it seems to be something specific to the CC2674P10 SoC.

Thanks for providing this additional context.  What SDK version are you using, and does this behavior exist with the default LP-EM-CC1354P10_1 ZNP project or is the device port necessary?

Regards,
Ryan

I am not observing the same with the default LP-EM-CC1354P10_1 ZNP code

Thus the issue could be either the device migration process, custom hardware, or the device should be fully erased before being re-programmed.

Regards,
Ryan

we are using SDK version sdk_7_10_02_23.

And, we are working with LP-EM-CC1354P10_6 ZNP code (not **P10_1")

We do migration to CC2674P10 RGZ package

_6/_1 should not make a difference for the issue of concern.  I used the same SDK version, the LaunchPad uses the RSK package, which is larger and has more pins than the RGZ version, but his shouldn't make a difference with proper migration.  Have you tried to debug your project to further determine why NV_OPER_ERROR (0xA) is returned (likely NV_OPER_FAILED in osal_nv_write_ex)?  What happens when you re-initialize without deleting the NV item?  Does this behavior happen for other NV items as well?

Regards,
Ryan

It seems this issue went away when I re-enabled the antenna switching. Of course that makes no sense and should not affect this, so I guess it maybe was issue with firmware installation, or the erase thing you mentioned above

it looks like NV memory is corrupted after startup. Items do not exist. I have to delete each one first then initialize and then I can write them

Start Time: 16.02.2024 16:46:08

<TX>04:46:08.85 COM59 SYS_PING (0x2101)

<RX>04:46:08.86 COM59 SYS_PING_RESPONSE (0x6101)
    Capabilities: System, AF, ZDO, Util, GP, AppConfig (0x659)

<TX>04:46:33.66 COM59 SYS_OSAL_NV_WRITE (0x2109)
    Id: 0x0003
    Offset: 0x00
    Len: 0x01
    Value: . (0x03)

<RX>04:46:33.67 COM59 SYS_OSAL_NV_WRITE_SRSP (0x6109)
    Status: NV_OPER_ERROR (0xA)

<TX>04:46:53.17 COM59 SYS_OSAL_NV_DELETE (0x2112)
    Id: 0x0003
    Len: 0x0001

<RX>04:46:53.17 COM59 SYS_OSAL_NV_DELETE_SRSP (0x6112)
    Status: SUCCESS (0x0)

<TX>04:47:02 COM59 SYS_OSAL_NV_ITEM_INIT (0x2107)
    Id: 0x0003
    Len: 0x0001
    InitLen: 0x01
    InitValue: . (0x00)

<RX>04:47:02.03 COM59 SYS_OSAL_NV_ITEM_INIT_SRSP (0x6107)
    Status: 9 (0x9)

<TX>04:47:13.54 COM59 SYS_OSAL_NV_WRITE (0x2109)
    Id: 0x0003
    Offset: 0x00
    Len: 0x01
    Value: . (0x03)

<RX>04:47:13.55 COM59 SYS_OSAL_NV_WRITE_SRSP (0x6109)
    Status: SUCCESS (0x0)

<TX>04:47:19.27 COM59 SYS_RESET (0x4100)
    Type: 0x00 (HARD RESET) (0x0)

<RX>04:47:21.33 COM59 SYS_RESET_RESPONSE (0x4180)
    Reason: 0x00
    TransportRev: 0x02
    Product: 0x01
    MajorRel: 0x02
    MinorRel: 0x07
    HwRev: 0x01

<TX>04:47:38.5 COM59 SYS_OSAL_NV_WRITE (0x2109)
    Id: 0x0057
    Offset: 0x00
    Len: 0x01
    Value: . (0x00)

<RX>04:47:38.51 COM59 SYS_OSAL_NV_WRITE_SRSP (0x6109)
    Status: SUCCESS (0x0)

<TX>04:48:12.7 COM59 APP_CNF_BDB_SET_CHANNEL (0x2F08)
    isPrimary: TRUE (0x1)
    Channel: CHNL_0x00002000 (0x2000)

<RX>04:48:12.71 COM59 APP_CNF_BDB_SET_CHANNEL_SRSP (0x6F08)
    Status: SUCCESS (0x0)

<TX>04:48:26.13 COM59 APP_CNF_BDB_SET_CHANNEL (0x2F08)
    isPrimary: FALSE (0x0)
    Channel: NONE (0x0)

<RX>04:48:26.13 COM59 APP_CNF_BDB_SET_CHANNEL_SRSP (0x6F08)
    Status: SUCCESS (0x0)

<TX>04:48:42.13 COM59 APP_CNF_BDB_START_COMMISSIONING (0x2F05)
    CommissioningMode: (0x04) Network Formation (0x4)

<RX>04:48:44.77 COM59 APP_CNF_BDB_START_COMMISSIONING_SRSP (0x6F05)
    Status: SUCCESS (0x0)

<RX>04:48:44.77 COM59 APP_CNF_BDB_COMMISSIONING_NOTIFICATION (0x4F80)
    Status: 1 (0x1)
    Commissioning Mode: 0x02 (Formation) (0x2)
    Commissioning Mode: 0x04 (Network Formation) (0x4)

<RX>04:48:44.97 COM59 ZDO_STATE_CHANGE_IND (0x45C0)
    State: 8 (0x8)

<RX>04:48:45.26 COM59 ZDO_STATE_CHANGE_IND (0x45C0)
    State: 8 (0x8)

<RX>04:48:45.82 COM59 ZDO_STATE_CHANGE_IND (0x45C0)
    State: 9 (0x9)

<RX>04:48:45.82 COM59 APP_CNF_BDB_COMMISSIONING_NOTIFICATION (0x4F80)
    Status: 0x00 (Success) (0x0)
    Commissioning Mode: 0x02 (Formation) (0x2)
    Commissioning Mode: 0 (0x0)

<TX>04:49:02.09 COM59 UTIL_GET_DEVICE_INFO (0x2700)

<RX>04:49:02.09 COM59 UTIL_GET_DEVICE_INFO_RESPONSE (0x6700)
    Status: SUCCESS (0x0)
    IEEEAddr: 0x00124B003246950E
    ShortAddress: 0x0000
    DeviceType: COORDINATOR, ROUTER, END_DEVICE (0x7)
    DeviceState: DEV_ZB_COORD (0x9)
    NumAssocDevices: 0x00
    AssocDevicesList

Tim had observed that the issue was resolved once they modified NVOCMP_PAGES which had changed during migration.  Here is some documentation on NV allocations, can you please confirm that both Project Properties and SysConfig settings are consistent before/after the migration process?

Regards,
Ryan