CCS/CC2652P: Program enter un-expected while() loop

Hi Kimi,

It looks like your NV section might have been corrupted for some reason. In the test, do they control the state of the software or is it free-running on the side?

While you could break from it, I can't say anything about the NV state after this, you would most likely want to clean it up and try to recover it manually again (as it seems it can't recover itself based on the while lock). 

Hi Kimi,

NVOCMP_RECOVER_ERASE could occur due to power poss after NV page compaction is finished but before erasing the PGXSRC page, or another unexpected page state value is determined:

#if (NVOCMP_NVPAGES != NVOCMP_NVONEP)
    else if(noPgXsrc)
    {
      // Power lost during compaction in progress
      if(noPgXdst)
      {
        action = NVOCMP_RECOVER_COMPACT;
      }
      // Power lost after compaction done, but before erasing PGXSRC page
      else
      {
        action = NVOCMP_RECOVER_ERASE;
      }
    }
    else if(noPgXdst)
    {
      action = NVOCMP_NORMAL_RESUME;
    }
    else if(noPgAct || noPgFull)
    {
      action = NVOCMP_RECOVER_ERASE;
    }

Can you determine which of these cases apply?

Regards,
Ryan

Hi Ryan,

It hit first "action = NVOCMP_RECOVER_ERASE;"

Hi Kimi,

There have been some changes to the NVOCMP driver recently which could resolve this issue, please evaluate with the following nvocmp.c file:nvocmp.c

Can you also provide a NV flash memory capture when the problem occurs?  This will help the Software Development Team further identify the exact issue.

Regards,
Ryan

Hi Ryan,

Can I replace the nvocmp.c directly?

Please tell me how to read NV section flash. Thank you

Hi Kimi, Ryan,

I verified the new nvocmp.c. It seems work. Below list my test.

HW:

one CC2652 Launchpad ( flashed with zc_light_CC26x2R1_LAUNCHXL_tirtos_ccs )
one CC1352P-2 launchpad (flashed with zed_sw_CC1352P_2_LAUNCHXL_tirtos_ccs )
also use one CC2531 dongle to sniff Zigbee packet (with Ubiqua)

One Power supply.

Test Steps:

1. power up CC2652 Launchpad & CC13352P-2 Launchpad.
2. Let CC1352P-2 join CC2652
3. On CC13352P-2 Launchpad, remove all the jumpers between XDS110 & CC1352P. Use Power supply to connect the 3V3, GND of CC13352P-2 Launchpad.
4. Power on CC13352P-2 Launchpad (Set Power supply to 3V)
5. Slowly decrease the voltage (0.1V every 1~2 sec) from 3v to 1.9v. (Fron sniff, CC1352P doesn't send out packet)
6. wait for around 3~5 min.
7. Slowly increase the voltage from 1.9 V to around 3V
==> if issue happen, CC1352P cannot send out packet even voltage is up to 3V
8. repeat 5~7

with old nvocmp.c, the issue can be reproduced around 5 times.
With new nvocmp.c, I tested for over 20 times (over 3 hours) and still cannot reproduce the issue.

Jerry Kuo Since you can reproduce this on your LaunchPad, can you help to provide a NV flash memory capture when the problem occurs as requested by Ryan Brown1?

This basically entails reading out the memory of the NV flash area after the issue occurs, however since the modified nvocmp file appears to address the issue then no further investigation may be required.

Regards,
Ryan

Hi Ryan,

Bad news, after replace the file, we do the same test. Sometimes, device does not rejoin(does not send beacon) event execute Zstackapi_bdbResetLocalActionReq(it should send beacon in our application). But LED and button wok correctly? Do you have any suggestion? BTW. Is it possible stay in debug mode after reset? Thank you

Hi Kimi,

From your description it would appear that the device no longer gets caught in a while loop yet still has NV corruption on a restart.  Is any radio activity possible at this time?  Would you be able to provide the flash memory contents during this state?  You can debug a running target by selecting Debug Configuration -> Program -> Load symbols only inside of CCS.

Regards,
Ryan

Hi Ryan,

We do not add application when reboot, we follow the zstack.

In my test. when ZED join ZC

Normal case : reboot the ZED, program enter zcl_samplesw.c --> zclSampleSw_ProcessCommissioningStatus() --> BDB_COMMISSIONING_PARENT_LOST

NG case : program does not enter zclSampleSw_ProcessCommissioningStatus() --> BDB_COMMISSIONING_PARENT_LOST after reboot. we try to "factory new" the device by Zstackapi_bdbResetLocalActionReq(). After reset, we use Zstackapi_bdbStartCommissioningReq() to join new ZC but we do not see the beacon from ZED

8015.20200316_noRF.zip

Thanks for providing the device's memory contents, I will have our NV driver expert check for inconsistencies.  I assume the default FLASH_NV_BASE of 0x52000 and FLASH_NV_SIZE of 0x4000 is used?  Does the device not have any radio activity and may it be related to your other E2E post?  https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/888891 

Regards,

Ryan

Hi Ryan,

We do not change the FLASH_NV_BASE(0x52000) and FLASH_NV_SIZE(0x4000). I add several customer NV define(showing below) in zcomdef.h

// NV Items Climax proprietary
#define ZCD_NV_FACTORY_RESET 0x02FE

//Climax define

#define ZCD_NV_FOLLOW_INPUT_TIME 0x0303
#define ZCD_NV_INPUT_LEVEL 0x0304
#define ZCD_NV_WORK_MODE 0x0305
#define ZCD_NV_OUTPUT_LEVEL 0x0306
#define ZCD_NV_IAS_CIE_ADDRESS_ID 0x0307

#define ZCD_NV_POLL_CONTROL_CHECK_IN_INTERVAL 0x0308
#define ZCD_NV_POLL_CONTROL_LONG_POLL_INTERVAL 0x0309
#define ZCD_NV_POLL_CONTROL_SHORT_POLL_INTERVAL 0x030A
#define ZCD_NV_POLL_CONTROL_FAST_POLL_TIMEOUT 0x030B

About the RF activity, I will reply in another post. Maybe they are the same issue but we cannot confirm.

In this post, we see no RF activity after NV patch. But the other post use old program(no NV patch)

Hi Kimi,

I do not see any issues with the flash memory contents that you provided.  This is exported during its broken state, correct?  Please also provide a memory export of the device in its working state so that we can compare them.

As the original issue is resolved I think we can continue discussing RF communication on the other thread.  If there is any further evidence of NV corruption then we will continue this thread.

Regards,
Ryan

Hi Ryan,

I provide 3 files to you (new program, join network and work correctly, no RF activity)

20200318_CC1352P NV.zip

OK, I will update RF activity issue in the other post.

Hi Ryan,

Do you have any response from you memory export about my last flash files?

Hi Kimi,

The Software Development Team is continuing to parse/evaluate but there is little concern of NV corruption based on the findings from the other E2E thread.

Regards,
Ryan

They have asked for “NVOCMP_nvHandle” content when the problem happens.  Using CCS debug you can view it from the Expressions window of CCS, otherwise you must locate the variable and save 46 bytes from there.

Regards,
Ryan

Hi Ryan,

OK, I will update the data when I get.

Hi Ryan,

For your reference