• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 56 subscribers
  • Views 234 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.

CC2530: ZED Rejoin issue - BDB_COMMISSIONING_FAILURE

Mario DW
Genius 3145 points
Part Number: CC2530

A ZED "disappeared" from the network after several weeks for a currently unknown reason.

Power cycling the device did not help (tried several times).

A procedure is in place so that the ZED  calls

      bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_FINDING_BINDING | BDB_COMMISSIONING_MODE_INITIATOR_TL);

after pressing a button for 5 seconds.
This was attempted several times as well without success.  I can not ascertain that the expected code was called because the expected side effect (a blinking led) did not occur.

While debugging with IAR, keeping the NVRAM memory intact, the device initially did not join the network.

Upon entering '..._ProcessCommissioningStatus(bdbCommissioningModeMsg_t* bdbCommissioningModeMsg)',

status corresponds to BDB_COMMISSIONING_FAILURE .

The _ProcessCommissioningStatus method is entered only one - I conclude that no commissioning is attempted again.

I set a breakpoint in the bdb_event_loop and it looks like this was the first event occuring.

Unfortunately after moving the breakpoint several times (and resetting between debug runs), this device appeared on the network again and is currently doing so consistently.

So that shows that the network information was not lost.

As far as I can see, my sniffer logs only show the rejoin request at the time where it succeeds - there are no rejoins requests before that.

My questions are the following:

- BDB_COMMISSIONING_FAILURE is a state that is not handled in the sample codes.  I would like to act on that - what is the recommendation?

- Any idea what might be a root cause - what to look at when it happens again ?

- Any other suggestion to make the ZED rejoin the network in such a case?

  • 0
    TI__Guru**** 202086 points

    Hey Mario,

    A ZED should not use BDB_COMMISSIONING_MODE_NWK_FORMATION and doing so may cause the BDB_COMMISSIONING_FAILURE.  I would expect that the BDB_COMMISSIONING_PARENT_LOST case would lead to a SAMPLEAPP_END_DEVICE_REJOIN_EVT timer after BDB_COMMISSIONING_NETWORK_RESTORED is found to not be true.  This leads to bdb_ZedAttemptRecoverNwk, which you could attempt for your application.  Thanks for the information you've provided thus far.  If the NV is proven to be intact and a rejoin eventually succeeds then there might be something which changed in the Zigbee network or radio hardware.  It would help to reliably recreate the issue to further understand and debug what the issue is.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3145 points

    Thenk you Ryan for this feedback.

    Ok, I am removing the BDB_COMMISSIONING_MODE_NWK_FORMATION  from the code where this was present - hopefully that avoids entering the unhandled case

    There is already a listener for the *APP_END_DEVICE_REJOIN_EVT which calls  bdb_ZedAttemptRecoverNwk(); .

    So basically, I should check if that gets called if I get another blocking situation.

     

    I do not think something changed in the network or radio hardware.  I have this unit on my home zigbee network for real life testing and I left it running for a few days to see if it would regain the network by itself.  It regained the network in the hour or so that I was debugging it (I was disappointed that it did).  I have about 20 other devices running fine, most of other types, a few of the same type.

     

    I did not see BDB_COMMISSIONING_PARENT_LOST  happen during debug (I think I should have seen it if it occured), The rejoin delay did not seem to be started because the was not reached.  I call "bdb_StartCommissioning(BDB_COMMISSIONING_REJOIN_EXISTING_NETWORK_ON_STARTUP);" at the end of the initialisation process.

    It's not so clean to not have a fallback default case in the _ProcessCommissioningStatus bdb callback for the "switch(bdbCommissioningModeMsg->bdbCommissioningMode)", but I am not sure what I should do in the default case:

    Maybe I should add the *APP_END_DEVICE_REJOIN_EVT timer when the bdbCommissioningMode is not handled in the CommissioningStatusCB .

     

  • 0 in reply to Mario DW
    TI__Guru**** 202086 points

    BDB_COMMISSIONING_REJOIN_EXISTING_NETWORK_ON_STARTUP is the same value as BDB_COMMISSIONING_INITIALIZATION.  Initialization notification should only be successful, with the exception of a ZED's BDB_COMMISSIONING_PARENT_LOST notification which should be handled in turn.  You could check ZCD_NV_BDBNODEISONANETWORK to see whether the ZED has network information stored in its NV, and jump-start the APP_END_DEVICE_REJOIN_EVT timer if the BDB_COMMISSIONING_PARENT_LOST case is failing to be reached by the BDB.

    Regards,
    Ryan