CC2630: Zstackapi_sysResetReq leads to new IEEE address

Philipp Sperber

Part Number: CC2630
Other Parts Discussed in Thread: Z-STACK

HI,

I'm facing the problem that after I receive a Leave Indication on my SED I want to do a system reset and delete all NWK information. Unfortunately when I then proceed to join the same network again my device has the IEEE address of 0xFFFFFFFF00000000. I attached a sniffer log of this process. Here is the code snippet of the leave process:

case zstackmsg_CmdIDs_ZDO_LEAVE_IND:
    {
      MSTI_setPollRate(0);
      deactivateSwitch();
      zstack_sysResetReq_t zstack_sysResetReq = {0};
      zstack_sysResetReq.newNwkState = true;
      zstack_sysResetReq.type = zstack_ResetTypes_DEVICE;
      (void)Zstackapi_sysResetReq(ztsEntity, &zstack_sysResetReq); 
    }
    break;

This is not the behavior I need. Is my Reset Request incorrect or why is the IEEE address changing?

Regards,

Philipp

IEEE_Bug.zip

over 7 years ago

0 YiKai Chen over 7 years ago

Guru 735695 points

How do you do factory reset?

0 Philipp Sperber over 7 years ago in reply to YiKai Chen

Intellectual 670 points

I dont understand the question. I only make a sysReset with the newNwkState parameter as true which according to the documentation should:

/**
* Set this flag to true to disregard the values stored in non-volatile
* and restart fresh.
*/
bool newNwkState;

It works because the device doens't remember the network it was part of but I don't understand why it changes the IEEE address of the device.
I'm using the Z-Stack HA 1.2.2.a

0 YiKai Chen over 7 years ago in reply to Philipp Sperber

Guru 735695 points

I can see your joined device has correct IEEE address in your sniffer log. Do I miss anything? Or you can point out which packet number show the issue you mentioned.

0 Philipp Sperber over 7 years ago in reply to YiKai Chen

Intellectual 670 points

I have a different sniffer so I cant tell which packet number it is but I attached a picture of my sniffer which shows that after the Leave, the next Association Request by my device comes with a NWK Src of FFFFFFFF00000000.

0 YiKai Chen over 7 years ago in reply to Philipp Sperber

Guru 735695 points

I use Ubiqua and Network Analyzer of Simplicity Studio 4 from SiLabs to open your sniffe log and don't see the same issue. Do you use Network Analyzer of Simplicity Studio 4? I suppose this is an tool issue from Silabs.

0 Philipp Sperber over 7 years ago in reply to YiKai Chen

Intellectual 670 points

could you be so kind to send me a screenshot of what you see in your sniffer?

Regards,

Philipp

0 YiKai Chen over 7 years ago in reply to Philipp Sperber

Guru 735695 points

I cannot access to my desktop so I will do screenshot tomorrow. Do you use Network Analyzer in Simplicity Studio 4?

0 Philipp Sperber over 7 years ago in reply to YiKai Chen

Intellectual 670 points

Ryan Brown1 (3460875) I would need some fast clarification on this because it presents a major Bug and I can easily reproduce it on different HW Samples and also if I use a DSLK to join and a GLK. Interestingly when I use the GLK I get the same Error but the new IEEE address is different. But it is still always the same.

0 YiKai Chen over 7 years ago in reply to Philipp Sperber

Guru 735695 points

I suppose this is still the issue on your network Analyzer.

0 Ryan Brown1 over 7 years ago in reply to Philipp Sperber

TI__Guru**** 222647 points

Philipp,

I am able to see the error in question on packet #2153 of your sniffer log, I am passing this information along to the Software Development Team for further evaluation.

Regards,
Ryan

0 YiKai Chen over 7 years ago in reply to Philipp Sperber

Guru 735695 points

Philipp Sperber After Ryan points out, I see the same trouble in my sniffer. I don't check to the end of your sniffer log and the problem happens on 3rd association process. Will wait Ryan to check what is the root cause of this.

0 Jose Maria Alvarez over 7 years ago in reply to Philipp Sperber

Genius 3415 points

Hi Philip,

I'm not able to reproduce this behavior. Can you test this again with a fresh new project and monitor the network with Ubiqua? as YK says, this can be a decoding failure.

0 Ryan Brown1 over 7 years ago in reply to YiKai Chen

TI__Guru**** 222647 points

Hi Philipp,

The CCFG could somehow be corrupted, is the issue still present if you comment out the following IEEE address check from taskFxn in main.c?

    /*
     * Copy the extended address from the CCFG area
     * Assumption: the memory in CCFG_IEEE_MAC_0 and CCFG_IEEE_MAC_1
     * is contiguous and LSB first.
     */
    memcpy(user0Cfg.extendedAddress,
           (uint8_t *)&(__ccfg.CCFG_IEEE_MAC_0), EXTADDR_LEN);

    // Check to see if the CCFG IEEE is valid
    if(memcmp(user0Cfg.extendedAddress, dummyExtAddr, EXTADDR_LEN) == 0)

Have you altered the ccfg.c file or use a custom bootloader configuration?

Regards,
Ryan

0 Philipp Sperber over 7 years ago in reply to Ryan Brown1

Intellectual 670 points

Hi Ryan,

When I comment out the complete code it looks like my device has the IEEE address of all 0. The first association Request in the log. When I comment out only the

memcpy(user0Cfg.extendedAddress,
(uint8_t *)&(__ccfg.CCFG_IEEE_MAC_0), EXTADDR_LEN);

the address doesn't change after Reset but it isn't the correct address.

Yes I edited the config file and the bootloader settings. I also check which kind of hardware version it is to set the correct backdoor pin. I attached the file and the sniffer log to the picture.

1638.IEEE_Bug.zip

0 Ryan Brown1 over 7 years ago in reply to Philipp Sperber

TI__Guru**** 222647 points

Hi Philipp,

I would actually expect the inverse to be true, at any rate please try commenting out the entire "if memcmp" statement instead. Can you share your config file and bootloader settings?

Regards,
Ryan

0 Philipp Sperber over 7 years ago in reply to Ryan Brown1

Intellectual 670 points

Hi Ryan,

the Config File is in the .zip folder. This file contains the bootloader settings correct?

0 Philipp Sperber over 7 years ago in reply to Ryan Brown1

Intellectual 670 points

Yes you're are right when I run it with the if commented out (like in the attached picture) then the address doesn't change but is incorrect.

0 Philipp Sperber over 7 years ago in reply to Philipp Sperber

Intellectual 670 points

Ryan Brown1 is there an update on this topic? It is urgent

Regards,

Philipp

0 Ryan Brown1 over 7 years ago in reply to Philipp Sperber

TI__Guru**** 222647 points

I apologize for the delay as it is difficult to replicate this issue. I also mistakenly thought that your previous post insinuated a random IEEE address value. Since it is all 0x00 this shows that the CCFG NV area is being correctly cleared, at which point the Primary IEEE Address is copied back into the CCFG. However you have noticed some cases where the NV re-init is filling some memory areas with 0xFF instead. As I mentioned before, the Software Development Team will have to comment on this. In the meantime you could just skip the CCFG IEEE check and directly copy from the Primary IEEE Address location (memcpy inside the if statement) each time instead.

Regards,
Ryan

Zigbee & Thread

Zigbee & Thread forum

CC2630: Zstackapi_sysResetReq leads to new IEEE address