CC2652P: Clear NV problem

Alejandro Ismael

Part Number: CC2652P

Tool/software:

Hello,

I am working with the ZStack ZNP project (SDK v4.40.4.04). I would like to know the appropriate command to send in order to clear the linked devices table, as when reaching the maximum limit (configured at 48 devices, in my case), I have no way to add device number 49. That is, even if device 48 sends a "Leave," the devices table still seems to be full.

I have tried sending a "Leave Request" to devices with the possibility of "Rejoin," but that doesn't solve the problem either.

I also tried, during the module's initialization, sending the SYS_OSAL_NV_WRITE command in the following way: FE 05 21 09 03 00 00 01 03 2C, then sent the module reset command FE 01 41 00 00 40. Upon reconfiguring the module, it starts functioning with the network created and recognizing the devices it was previously paired with.

The main problem we currently face is the inability to remotely clear the devices table, which forces a visit to the customer's home in order to reprogram the device, allowing us to pair new devices again. (We currently have more than 15k coordinators installed).

I am looking for guidance on the correct command or procedure to completely clear the linked devices table, so that I can start pairing new devices without the limitation imposed by the previous ones.

Any assistance or documentation regarding this issue would be greatly appreciated.

over 1 year ago

0 Toby over 1 year ago

TI__Mastermind 35070 points

Hi,

So with using the SYS_OSAL_NV_WRITE, you are able to achieve the removal of an entry from the linked devices table?

If yes, my immediate thought regarding the ability to remotely clear the devices table, you could invoke the SYS_OSAL_NV_WRITE after conditions which you expect the device to have been removed.

E.g. after the host instructs the ZNP to send a "Leave Request", then afterwards the host could send a SYS_OSAL_NV_WRITE.

Thanks,
Toby

0 Alejandro Ismael over 1 year ago in reply to Toby

Prodigy 10 points

Hi Toby,

Thanks for your response.

First of all, the idea of remotely sending the SYS_OSAL_NV_WRITE command seems to be the best option we have and is what we plan to do.
However, the main issue we have is that the SYS_OSAL_NV_WRITE command with the data sent (FE 05 21 09 03 00 00 01 03 2C) does not remove any device.

Unfortunately, the only way we have managed to remove devices so far has been by reprogramming the equipment.

Regards.

0 Toby over 1 year ago in reply to Alejandro Ismael

TI__Mastermind 35070 points

Do these posts help?

0 Alejandro Ismael over 1 year ago in reply to Toby

Prodigy 10 points

Hi Toby,

I used the UTIL_GET_DEVICE_INFO command to get the paired devices. I received the following response:

FE 10 67 00 00 DC 08 D1 26 00 4B 12 00 00 00 07 09 01 85 AA

During the pairing of the device (short addr 0x85AA), I obtained its MAC: A4 C1 38 84 AF 78 9C 6F

Now, I’m trying to execute the ZDO_SEC_DEVICE_REMOVE command:

I send FE 25 44 A4 C1 38 84 AF 78 9C 6F CK -> Response: FE 01 65 44 C8
I send FE 25 44 6F 9C 78 AF 84 38 C1 A4 CK -> Response: FE 01 65 44 C8

I don’t understand what I’m doing wrong, but I can’t remove the device in any way; it always responds with 0xC8 (Unknown device).

I also tried the SYS_OSAL_NV_DELETE command, but I don’t know how to obtain the "Id" and "ItemLen" parameters.

If you could help me with this, I’d really appreciate it.

Best regards,

0 Toby over 1 year ago in reply to Alejandro Ismael

TI__Mastermind 35070 points

Thanks for sharing more details of your investigation.

I will look into and provide an update within 3 business days.

0 Alejandro Ismael over 1 year ago in reply to Toby

Prodigy 10 points

Hi Toby,

Thank you for your help.

Best regards,

0 Toby over 1 year ago in reply to Alejandro Ismael

TI__Mastermind 35070 points

The IEEE addresses in the MT API are MSB first when in reality it's LSB. So if you want to remove A4 C1 38 84 AF 78 9C 6F then you have to enter it as 6F 9C 78 AF 84 38 C1 A4.

0 Alejandro Ismael over 1 year ago in reply to Toby

Prodigy 10 points

Hi Toby,

As I mentioned in the previous response,

I am sending: FE 25 44 A4 C1 38 84 AF 78 9C 6F CK

And I receive: FE 01 65 44 C8.

If I change the order from MSB to LSB:

FE 25 44 6F 9C 78 AF 84 38 C1 A4 CK

I still get: FE 01 65 44 C8.

Any other ideas?

Thanks.

0 Alejandro Ismael over 1 year ago in reply to Toby

Prodigy 10 points

Hi Toby, sorry for insisting, but this problem is causing a delay in the production of our product.

Do you have any other ideas in mind?

If you can help me, I would greatly appreciate it.

Best regards.

0 Ryan Brown1 over 1 year ago in reply to Alejandro Ismael

TI__Guru**** 219717 points

Hi Alejandro,

Toby is on a well-deserved vacation until 9/9, so I can try to assist until he returns. Can you provide a sniffer log of your network, and what is the topology? I.e. is the device you want to remove directly associated to the ZNP or is it connected to another ZR parent?

Are you able to debug your ZNP device? If so then you can follow MT_ZdoSecDeviceRemove -> ZDSecMgrDeviceRemoveByExtAddr -> ZDSecMgrEntryLookupExt, at which point ZDSecMgrExtAddrLookup likely fails which returns the ZNwkUnknownDevice status. Then you'd be able to confirm whether the extAddr parameter matches the extended address of the device in question.

You also have the opportunity to use UTIL_ADDRMGR_NWK_ADDR_LOOKUP to determine the ExtAddr based on the NwkAddr being used. You can send a ZDO_IEEE_ADDR_REQ to the remote device to make sure that the correct IEEEAddr is returned in the ZDO_IEEE_ADDR_RSP. UTIL_ASSOC_COUNT and UTIL_ASSOC_FIND_DEVICE are also helpful in this regard. Please provide details of the information returned when you attempt these APIs.

If necessary, you could define MT_APP_FUNC in your project and the APP_MSG / APP_USER_TEST to create a custom MT API which replicates the contents of ZDApp_LeaveUpdate. https://e2e.ti.com/f/1/t/1028567

Regards,
Ryan

Zigbee & Thread

Zigbee & Thread forum

CC2652P: Clear NV problem