CCS/CC1352P: No RF signal sends out from CC1352P device after it runs 2 days.

Ryan Brown1 We had seen similar issue since using rev.C chip. Can you provide an API so we can check if RF core is still alive? We might also need API to reset RF core.

Are you referring to this E2E post?  https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/771406 

Also, do you believe it is related to your other recent request?  https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/887362 

Were any device resets performed during these moves?  I will have the Platform Software Team comment on your radio API questions.

Regards,
Ryan

Hi Ryan,

We do not reset any devices during this test.

We have 2 rejoin rule

1. When orphan, start DIO52_END_DEVICE_REJOIN_DELAY (this is default function, we change DIO52_END_DEVICE_REJOIN_DELAY from 1sec to 20min)

2. Press button, stop DIO52_END_DEVICE_REJOIN_DELAY and restart with new time(showing)

Timer_stop(&EndDeviceRejoinClkStruct);
Timer_setTimeout( EndDeviceRejoinClkHandle, 100);
Timer_start(&EndDeviceRejoinClkStruct);

Our test is showing below

1. ZED join ZC

2. ZED change Orphan(In this case, we put ZED into shielding room)

3. Move ZED close to ZC

ZED does not rejoin within 2~3 hr. Our QA team press button on the ZED, it still does not rejoin. I check ZED in shielding room within 1 hr, there is no beacon event I press button.

In our application, we have another button. It can toggle the LED on the ZED, they work correctly. Looks like only RF does not work

Hi Kimi,

How does the device's behavior change if you perform a hardware or software reset?  Can this be easily replicated with TI LaunchPads and example projects?  Would it be possible to debug Zstackapi_bdbZedAttemptRecoverNwkReq -> processBdbZedAttemptRecoverNwkReq -> bdb_ZedAttemptRecoverNwk -> ZDOInitDevice? 

Regards,
Ryan

Hi Ryan,

As you know, we have RF issue when do the following test

1. ZED join ZC --> decrease voltage down to 1.8v --> increase voltage to 3v --> sometimes, we lost rf function but GPIO work correctly --> power cycle ZED --> no rf function but GPIO work correctly

we get the following result when debug. Looks like ZStack lost network state(bdbNodeIsOnANetwork is 0) and customer NV cannot be write

2. ZED join ZC --> ZED orphan --> ZED try to rejoin by rejoin timer or press button --> sometimes, we lost rf function but GPIO work correctly --> power cycle ZED --> no rf function but GPIO work correctly

--> Try to replicated

Hi Kimi,

At this point it has been determined that there are no issues with the RF core, the device is simply not sending any RF packets over-the-air since bdb_ZedAttemptRecoverNwk fails given that bdbNodeIsOnANetwork is false.  After joining a network this value should really only become false alongside intent to perform a Factory New state.  But in this case the device does not reset to FN during a power cycle since ZCD_STARTOPT_DEFAULT_CONFIG_STATE is not set as a startup option.  The application does not appear to know how to handle this conflict and thus is stuck in a bricked/frozen state.

Can you please further debug your ZED to determine when bdbNodeIsOnANetwork is set to false (break inside bdb_setNodeIsOnANetwork and check the call stack)?  Does failure happen on every change to orphan state, otherwise is their any system behavior that can create the issue consistently?  I have not been able to replicate this issue from the default ZC light and ZED SW OTA projects inside SDK v3.40 and I cannot find any relevant information in the Z-Stack Release Notes.  I'm quite certain that this issue is related to your previous E2E thread in which you mention custom NV items, I also gather from your most recent post that in this fail state you can no longer write to the NV.  Are you using the NVINTF_SYSID_APP or NVINTF_SYSID_ZSTACK for these?  I recommend the former and that you reference the Application Non-Volatile Memory section of the User's Guide as well as the doorlock/doorlock controller examples for an instance of using the NV inside your application.

Regards,
Ryan

Hi Ryan,

It is difficult to debug "when bdbNodeIsOnANetwork is set to false". We need decrease/increase voltage in test(the debug break whem voltage too low). In our application, we do not change bdbNodeIsOnANetwork. It is controlled by zstack.

About NV

1. We use following api to read/write NV

osal_nv_item_init()

osal_nv_write()

osal_nv_read()

2. We remove all customer NV application, we still see the issue. The bdbNodeIsOnANetwork change to 0. After 

Zstackapi_bdbResetLocalActionReq(appServiceTaskId); We excute

zstack_bdbStartCommissioningReq_t zstack_bdbStartCommissioningReq;

zstack_bdbStartCommissioningReq.commissioning_mode = BDB_COMMISSIONING_MODE_NWK_STEERING;

Zstackapi_bdbStartCommissioningReq(appServiceTaskId,&zstack_bdbStartCommissioningReq);

We do not see the beacon

Hi Kimi,

It is good to know that the application NV items are not the issue.  processBdbResetLocalActionReq -> bdb_resetLocalAction -> bdb_setFN sets bdbNodeInOnANetwork to FALSE and writes the startup options for factory new, then for an orphaned device the system is reset in 500 ms:

void bdb_resetLocalAction(void)
{
  //Process reset as nwk leave if the device is on the network and is able to process it
  if((ZG_BUILD_JOINING_TYPE) && (bdbAttributes.bdbNodeIsOnANetwork) && (!(bdbAttributes.bdbCommissioningMode & BDB_COMMISSIONING_MODE_PARENT_LOST)))
  {
    NLME_LeaveReq_t leaveReq;
    // Set every field to 0
    memset( &leaveReq, 0, sizeof( NLME_LeaveReq_t ) );

    bdb_setFN();

    NLME_LeaveReq( &leaveReq );

    return;
  }
  else
  {
    bdb_setFN();

    ZDApp_ResetTimerStart( 500 );
  }
}

You should allow this to occur before calling Zstackapi_bdbStartCommissioningReq or else risk the behavior observed.

Regards,
Ryan