CC2650EMK: Stop sending data packets and stop Beacon Request

Hi Yuya,

Thank you for providing the sniffer log.  The behavior you mention occurs after 0x7E85 loses its connection to the coordinator and must rejoin after being orphaned.  Are the Temperature Measurement Report Attribute commands sent automatically, based on a bind located on the ZED, or are they triggered manually by the application?  If automatic, are you able to confirm that the bind is maintained through the rejoin process?  At any rate, it is apparent from the number of packet retries that 0x7E85 and the coordinator have a poor radio connection.  The devices should be moved closer together, have physical barriers/channel interferers removed, and/or increase their transmission power.

Please be aware that the CC2650 is not recommended for new Zigbee projects as it cannot support Z-Stack versions beyond 1.2.2 HA (deprecated several years ago) and does not have enough memory for a robust/reliable solution.  I recommend migrating to the CC2651R3 if possible.

Regards,
Ryan

Hi Ryan,

Thank you for the quick reply.

My reply is as follows.

Are the Temperature Measurement Report Attribute commands sent automatically, based on a bind located on the ZED, or are they triggered manually by the application?  

Ans. I think Temperature Measurement Report Attribute commands sent automatically, based on a bind located on the ZED. The device is set to reconnect automatically when it cannot find its coordinator.(Please see around 4:50 packet data.)

If automatic, are you able to confirm that the bind is maintained through the rejoin process?

Ans. I cannot confirm if the bind was maintained. Is there an API that I can check to see if the bind is maintained? 

The devices should be moved closer together, have physical barriers/channel interferers removed, and/or increase their transmission power.

Ans. I will try to change where I place the device.

Why is this device didnot send Orphan Notification and Beacon Request? 

Best regards,

Yuya 

You can refer to bindFindExisting (from BindingTable.c/h of the ZStackCore project) and/or read the ZCD_NV_BINDING_TABLE NV item with osal_nv_read. The device may not be attempting to rejoin if it has entered backoff mode (see similar backoff and rejoin E2E threads), but another option is that the application has crashed due to memory leakage/corruption or some other hardware assertion (further on-device debugging would be required to confirm).

Regards,
Ryan

I check memory leak and other problem using application debug.

Are there any reports of z-stack memory leaks or z-stack crashes in the forum? Is there any way for the application to know that the z-stack has stopped?

Best regards,

Yuya

You can search the E2E for threads pertaining to Z-Stack memory leaks and crashes.  As I've previously stated, Z-Stack HA 1.2.2a on the CC2650 is more susceptible to issues due to the device's limitations.

https://e2e.ti.com/f/1/t/906365 
https://e2e.ti.com/f/1/t/902631 

halAssertHandler will determine what action should be taken upon a code assertion.

Regards,
Ryan

The device may not be attempting to rejoin if it has entered backoff mode (see similar backoff and rejoin E2E threads)

Z-stack repeats dev_nwk_backoff and dev_nwk_desc state, but is it possible that the state never changes from dev_nwk_backoff?

What state would that be?

Best regards,

Yuya

Unless backoff timer is dead and disappeared, the device shouldn't never changes from dev_nwk_backoff state

Thank you for the quick reply.

That is, Device changes from dev_nwk_backoff when the backoff timer is disappeared?

In Z-Stack Home 1.2.2a implementation, ZDO_REJOIN_BACKOFF timer event would actually start with different timeout parameter zgDefaultRejoinScan and zgDefaultRejoinBackoff so it won't disappeared.

Yuya Murata said:

The device may not be attempting to rejoin if it has entered backoff

The above is taken from Ryan's reply.

I would like to know is the above state happen?

But does it mean that this state does not happen?

In Z-Stack Home 1.2.2a ZStackCore implementation, it will call osal_start_timerEx( ZDAppTaskID, ZDO_REJOIN_BACKOFF, zgDefaultRejoinScan ) to when startMode == MODE_RESUME and logicalType is end device in ZDO_StartDevice

In an attempt to avoid further confusion, please refer to Chapter 7 (Portable Devices) of the zstack_home_1_02_02a_44539\Documents\Z-Stack TI-RTOS Developer's Guide.pdf:

If the end device loses its parent while polling, it scans the currently active channel and attempts a secure rejoin, if it can’t find its network it will attempt a scan of all channels. If attempts fail for a secure rejoin (current and all channels), the network key is removed and the device will attempt a trust center rejoin (unsecure). When an end device is aged out, it will attempt to rejoin the network. Rejoin does not depend on state of Associate Permit flag. When the end device is in rejoin state (scan and rejoin attempts), it will be in the rejoin state for a defined period of time (15 minutes default) and then goes into a back off period(silent state) (15 minutes default), then cycle back to the rejoin state. These durations can be configured by the application image with the following code:
zstack_sysConfigWriteReq_t writeReq = {0};
// Set the rejoin state duration – 10 minutes (600,000 mSecs)
writeReq.has_rejoinScanDuration = true; // activate the parameter
writeReq.rejoinScanDuration = 600000;
// Set the back-off rejoin state duration – 10 minutes (600,000 mSecs)
writeReq.has_rejoinBackoffDuration = true; // activate the parameter
writeReq.rejoinBackoffDuration = 600000;
// Send the System Configuration Write Request
(void)Zstackapi_sysConfigWriteReq(appEntity, &writeReq);

Regards,
Ryan

I already read that document.
I understand the following.

If the end device loses its parent while polling, Z-stack state change from DEV_END_DEVICE to DEV_NWK_ORPHAN and send ORPHAN NOTIFICATION.
After that,  z-stack state change from DEV_NWK_ORPHAN to DEV_NWK_DISC and send BEACON REQUEST.
and z-stack repeats states DEV_NWK_DISC and DEV_NWK_BACKOFF.
z-stack do not send BEACON_REQUEST while that state is DEV_NWK_BACKOFF.

My device's configuration is as follows.

f8wConfig.cfg
-DDEFAULT_CHANLIST=0x00001000(only use)
-DREJOIN_BACKOFF=60000
-DREJOIN_SCAN =120000

I think the problem is that the z-stack state did not change from DEV_END_DEVICE to DEV_NWK_ORPHAN.
Have any of these issues been posted in forum?

I have a question for HALassertHandler.
My application is based on the SampleTemperatureSensor code.
Sample code already implement HALassertHandler.
Does this handler detect and work with z-stack errors without additional configuration.

Best regards,
Yuya

You are providing this forum with your theories but not providing any evidence based on your findings.  Have you debugged the device state during this application behavior?  You are able to search for similar instances/occurrences on the E2E forum.

HAL assertions act on hardware/stack failure but cannot be relied on for faulty behavior based on application code implementation.

Regards,
Ryan

I'm sorry.
I had debug my application using serial output.
Please see the attached file.

My application sends data to ZC every 10 seconds(TEMPSENSOR_DATASEND_EVENT.
After the application goes through ICall_wait, it queries the z-stack for state and outputs it via serial communication.

Best regards,
Yuya

debug.zip

Thank you for the logs.  zstack_DevState_NWK_ORPHAN is 10, so the seriallog.txt shows the device state change from DEV_END_DEVICE to DEV_NWK_ORPHAN, then DevState_NWK_DISC/DevState_NWK_BACKOFF which also reflects the orphan status.

Regards,
Ryan

Hi,

Unfortunately, I can't provide any logs as I don't have that issue with this debugged ZE.
I'm still debugging, so I'll ask again when I get the log.

I searched the forum with the words "Orphan Notification" but didn't find any similar issues.

Do I need to comment -DASSERT_RESET in f8wconfig.cfg to use HAL assertions reset?

Best regards,
Yuya

You would remove the "//" characters from "//-DASSERT_RESET" if you want the device to reset when ASSERT occurs.

Regards,
Ryan

Hi,

Thank you for the additional logs.  If you can confirm that ZDApp_StartJoiningCycle -> ZDApp_NetworkInit is being executed but is ineffectively rejoining the orphan device to the network then the Z-Stack radio layer could be caught in a fail state which may not trigger the assert.  In this case you should monitor the application behavior and call SystemResetSoft to restart the firmware.

Regards,
Ryan

Hi, 

I would like to check if HALassertHandler works.
So, I would like to how to easily activate HALassertHandler.
Do you have an idea?

and I found SystemResetSoft() function's document.
I know it is a TI-RTOS function, but is there any documentation?

Best regards,
Yuya

You should be able to use the HAL_ASSERT function to force a HAL assert.  SystemResetSoft -> SystemReset -> HAL_SYSTEM_RESET does not have documentation but is a write to the reset register, i.e. HWREGBITW( AON_SYSCTL_BASE + AON_SYSCTL_O_RESETCTL, AON_SYSCTL_RESETCTL_SYSRESET_BITN ) = 1;

Regards,
Ryan

Hi,

I am now trying to make sure HALAssertHandler works.
I have a few questions it.
1. Is HAL_ASSERT FUNCTION a macro defined in hal_assert.h?
2. Is the HAL_ASSERT_HANDLER called by this macro a function defined in halassert.c?
When ZD changed state from DEV_NWK_BACKOFF to DEV_NWK_DISC, z-stack call HAL_ASSERT_FORCED function(please see ZDApp.c Line 499).
I expected behavior is that the function defined in main.c(please see main.c Line 315) of Application is called and the debug statement is displayed. However, it did not work that way.

5141.ZDApp.c

#include <string.h>
#include <xdc/std.h>
#include <xdc/runtime/Error.h>
#include <xdc/runtime/System.h>

#include <ti/sysbios/BIOS.h>
#include <ti/sysbios/knl/Task.h>
#include <ti/sysbios/hal/Hwi.h>
#include <ti/sysbios/knl/Clock.h>

#include <ioc.h>

#include "ICall.h"
#include "Board.h"
#include "TIMACBoard.h"
#include "CryptoBoard.h"
#include <ti/sysbios/family/arm/cc26xx/Power.h>
#include <ti/drivers/crypto/CryptoCC26XX.h>

#include <ti/sysbios/family/arm/cc26xx/Power.h>
#include <ti/sysbios/family/arm/cc26xx/PowerCC2650.h> 
#include <ti/drivers/PIN.h>

#include <aon_rtc.h>
#include <prcm.h>

/* Header files required to enable instruction fetch cache */
#include <vims.h>
#include <hw_memmap.h>


#include <driverlib/watchdog.h>


//#include <ti/drivers/i2s.h>
#include "board_led.h"

#include "cpu.h"
#include "hw_types.h"
#include <inc/hw_ccfg.h>
#include <inc/hw_ccfg_simple_struct.h>

#include "pwrmon.h"
#include "nvoctp.h"
#include "tempsensor.h"
#include "zstackconfig.h"


		
//Sensor controller 
#include "scif.h"
#define BV(x)    (1 << (x))
#define TASKSTACKSIZE   512
#define TASK2STACKSIZE  512
//if you want to LED on, DEBUG_LED is 0,
//DEBUG_LED normal setting is 1 
#define DEBUG_LED  0

 float celsiusIR = 0;
 float celsiusDigi = 0;
 float ADC_Volts = 0;
 
 uint8_t g_test=0;
extern Semaphore_Struct mutex1;
 
Task_Struct task0Struct;
Char task0Stack[TASKSTACKSIZE];

Task_Struct task1Struct;
Char task1Stack[TASK2STACKSIZE];

/* Pin driver handle */
PIN_Handle ledPinHandle;
PIN_State ledPinState;

//PIN_Config ledPinTable[] = {
//    
//    Board_LED4 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,
//    Board_LED3 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,
//    Board_LED2 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,
//    PIN_TERMINATE
//};



//static PIN_State pinState; 

/******************************************************************************
 * CONSTANTS
 */

// IEEE Mode
#define RFC_MODE_IEEE PRCM_RFCMODESEL_CURR_MODE2

// Size of the Application Thread's Stack
#define MY_TASK_STACK_SIZE 1024

// Exented Address Length
#define EXTADDR_LEN 8

// Extended Address offset in FCFG (LSB..MSB)
#define EXTADDR_OFFSET 0x2F0

// Minimum voltage level need to run
#if !defined (MIN_VDD_RUN)
#define MIN_VDD_RUN         MIN_VDD_POLL
#endif

/******************************************************************************
 * MACROS
 */

// Macro to set the RF Mode
#define SET_RFC_MODE(mode) HWREG(PRCM_BASE + PRCM_O_RFCMODESEL) = (mode)

// Macro used to break a uint32_t into individual bytes
#define BREAK_UINT32(var, ByteNum) \
    (uint8)((uint32)(((var) >> ((ByteNum) * 8)) & 0x00FF))

/******************************************************************************
 * ZStack Configuration Structure
 */
zstack_Config_t user0Cfg =
{
    {0, 0, 0, 0, 0, 0, 0, 0}, // Extended Address
    {0, 0, 0, 0, 0, 0, 0, 0}, // NV function pointers
    0,                        // ICall application thread ID
    0,                        // stack image init fail flag
    MAC_USER_CFG
};

/******************************************************************************
 * LOCAL VARIABLES
 */

// Main application stack space
static Task_Struct myTask;
static Char myTaskStack[MY_TASK_STACK_SIZE];

// Used to check for a valid extended address
static const uint8_t dummyExtAddr[] =
    {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };

/******************************************************************************
 * EXTERNALS
 */

extern const ccfg_t __ccfg;

/*******************************************************************************
 * @fn          taskFxn
 *
 * @brief       Application thread starting function
 *
 * @param       a0 - argument 0, not used
 * @param       a1 - argument 1, not used
 *
 * @return      none
 */
Void taskFxn(UArg a0, UArg a1)
{
    /* Disallow shutting down JTAG, VIMS, SYSBUS during idle state
     * since TIMAC requires SYSBUS during idle. */
    Power_setConstraint(Power_IDLE_PD_DISALLOW);

    /* Initialize the Power Monitor */
    PWRMON_init();

    /* Initialize ICall module */
    ICall_init();

    {
        CryptoCC26XX_Params CryptoCC26XXParams;
        extern CryptoCC26XX_Handle CryptoCC26XXHandle;

        // Initialize the Crypto Driver
        CryptoCC26XX_init();
        CryptoCC26XX_Params_init(&CryptoCC26XXParams);
        CryptoCC26XXHandle = CryptoCC26XX_open(Board_CRYPTO, false,
                                               &CryptoCC26XXParams);
        if(!CryptoCC26XXHandle)
        {
            Task_exit();
        }
        Crypto_init();
    }

    /*
     * 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)
    {
        // No, it isn't valid.  Get the Primary IEEE Address
        memcpy(user0Cfg.extendedAddress,
               (uint8_t *)(FCFG1_BASE + EXTADDR_OFFSET), EXTADDR_LEN);
    }

    // Make sure the voltage level is high enough to operate
    while ( PWRMON_check( MIN_VDD_RUN ) == false )
    {
      // Add your own code to do something here, flash LED, sleep, something
      // For now, we will loop and wait for power comes up to the
      // MIN_VDD_RUN level.
    }

#if !defined (FEATURE_APP_NO_NV_INIT)
    /* Setup the NV driver for the ZStack thread */
    NVOCTP_loadApiPtrs(&user0Cfg.nvFps);
#endif // !FEATURE_APP_NO_NV_INIT

    if(user0Cfg.nvFps.initNV)
    {
        user0Cfg.nvFps.initNV(NULL);
    }

    /* Start tasks of external images */
    ICall_createRemoteTasks();

    /* Kick off application */
    Sensor_task(&user0Cfg.nvFps);
}


/*******************************************************************************
 * @fn          main
 *
 * @brief       entry function - standard C [main()]
 *
 * @param       none
 *
 * @return      none
 */



void main(){
  
    
    Task_Params taskParams;
    // set RFC mode to support IEEE802.15.4
    // Note: This must be done before the RF Core is released from reset!
    SET_RFC_MODE(RFC_MODE_IEEE);

    // enable iCache prefetching
    VIMSConfigure(VIMS_BASE, TRUE, TRUE);

    // Enable cache
    VIMSModeSet(VIMS_BASE, VIMS_MODE_ENABLED);

    /* Initialization for board related stuff such as LEDs
     * following TI-RTOS convention */
    PIN_init(BoardGpioInitTable);
    // Configure task.
  
    Task_Params_init(&taskParams);
    taskParams.stack = myTaskStack;
    taskParams.stackSize = MY_TASK_STACK_SIZE;
    taskParams.priority = 1;
    Task_construct(&myTask, taskFxn, &taskParams, NULL);
       
   
    /*1.Enable the wd*/
    WatchdogEnable();
    WatchdogStallEnable();
    WatchdogReloadSet(1500000*12);
    /*2.Enable reset on timeout */
    WatchdogResetEnable();
    /*3.Set it as NON maskable */
    WatchdogIntTypeSet(WATCHDOG_INT_TYPE_NMI);
     
#if DEBUG_LED
  ledPinHandle = PIN_open(&pinState, ledPinTable);
  PIN_setOutputValue(ledPinHandle,Board_LED3,0);
  for(int i = 0; i < 2050; i++)
  {
    for(int j =0; j<4000; j++)
    {
      //NOP
    }
  }
    PIN_setOutputValue(ledPinHandle,Board_LED3,0);

#endif    

    BIOS_start();   /* enable interrupts and start SYS/BIOS */
}

/*******************************************************************************
 *
@fn  
halAssertHandler
 *
 * @brief       HAL assert handler required by OSAL memory module.
 *
 * @param       none
 *
 * @return      none
 */
void halAssertHandler(void)
{
  	System_printf("halAssert occured\r\n\0");
    Hwi_disable();
    while(1) {}
}

/*******************************************************************************
 * @fn          exceptionHandler
 *
 * @brief       Exception Handler Loop
 *
 * @param       none
 *
 * @return      none
 */
void exceptionHandler()
{
  	System_printf("exceptionError occured\r\n\0");
    while(1) {}
}

/*******************************************************************************
 * @fn          smallErrorHook
 *
 * @brief       Error handler to be hooked into TI-RTOS
 *
 * @param       none
 *
 * @return      none
 */
Void smallErrorHook(Error_Block *eb)
{
    System_printf("smallError occured\r\n\0");
    while(1) {}
}

3. When is called hal_assert_handler defined in main.c? and How can I confirm that it works?
Best regards,
Yuya

I apologize for any confusion but you appear to be missing the objective of HAL asserts.  They are independent operations which occur when there is a hardware issue which could be caused by the application execution.  The user can determine what action is taken after a HAL assert happens (reset, blink lights, spin, etc.) but they should not directly call/force a HAL assertion.  Simply perform the action you wish to accomplish after reaching the code in question.

Regards,
Ryan