CCS/LAUNCHXL-CC1310: Polling and tracking stops after reset of sensor and collector

Hey Ryan,

I did not provide enough resources for you to understand my disconnect behavior. See below the functions handleMaxDataFail() and disassoCnfCb().

static void handleMaxDataFail(void)
{
    if(!CONFIG_RX_ON_IDLE)
    {
        /* stop polling */
        Ssf_setPollClock(0);
    }

    ApiMac_mlmeSetReqBool(ApiMac_attribute_RxOnWhenIdle, true);
    /* Initialize counter for re-join delay calculation */
    interimDelayTicks = Clock_getTicks();
    /* non beacon network or fh mode - update stats */
    Sensor_msgStats.syncLossIndications++;

    if(CONFIG_FH_ENABLE)
    {
        updateState(Jdllc_states_orphan);
        parentFound = false;
        /* start trickle timer for PCS */
        Ssf_setTrickleClock(fhPanConfigInterval,
                            ApiMac_wisunAsyncFrame_configSolicit);
    }
    else
    {
//__________________MY CHANGE START___________________
#ifndef POWER_MEAS
        // For debug purpose only
        System_printf("Entered handleMaxDataFail \r\n");
#endif
        if (auto_orphan_dis)
        {
        	Jdllc_sendDisassociationRequest();
        	auto_orphan_dis = false;
        }
//_________________MY CHANGE END____________________
    }

    devInfoBlock.dataFailures = 0;
}

AND

static void disassoCnfCb(ApiMac_mlmeDisassociateCnf_t *pData)
{
//____________________MY CHANGE START_______________________
#ifndef POWER_MEAS
            // For debug purpose only
            System_printf("Disc entered!\r\n");
#endif
//____________________MY CHANGE END_____________________________

    if(pData->status == ApiMac_status_success)
    {
        /* stop polling */
        if(!CONFIG_RX_ON_IDLE)
        {
            Ssf_setPollClock(0);
        }
        /* enable looking for new parent */
        parentFound = false;

        /* set devInfoBlock back to defaults */
        devInfoBlock.panID = CONFIG_PAN_ID;
        devInfoBlock.channel = JDLLC_INVALID_CHANNEL;
        devInfoBlock.coordShortAddr = 0xFFFF;
        memset(&devInfoBlock.coordExtAddr[0], 0x00, APIMAC_SADDR_EXT_LEN);
        devInfoBlock.devShortAddr = 0xFFFF;
        memset(&devInfoBlock.devExtAddr[0], 0x00, APIMAC_SADDR_EXT_LEN);
        devInfoBlock.beaconOrder = CONFIG_BEACON_ORDER;
        devInfoBlock.superframeOrder = CONFIG_SUPERFRAME_ORDER;
        /* Below two commented lines will be set by updateState()*/
        /*devInfoBlock.currentJdllcState = Jdllc_states_initWaiting;*/
        /*devInfoBlock.prevJdllcState = Jdllc_states_initWaiting;*/
        devInfoBlock.currentDevState = Jdllc_deviceStates_scanActive;
        devInfoBlock.prevDevState = Jdllc_deviceStates_scanActive;
        devInfoBlock.dataFailures = 0;
        devInfoBlock.pollInterval = CONFIG_POLLING_INTERVAL;

        /* change state back to initWaiting and print on UART */
        updateState(Jdllc_states_initWaiting);
    }

    if(pJdllcCallbacksCopy && pJdllcCallbacksCopy->pDisassocCnfCb)
    {
        pJdllcCallbacksCopy->pDisassocCnfCb(&pData->deviceAddress.addr.extAddr,
                                            pData->status);
    }

    if(macCallbacksCopy.pDisassociateCnfCb != NULL)
    {
        macCallbacksCopy.pDisassociateCnfCb(pData);
    }
//_____________MY CHANGE START____________
#ifdef AUTO_RESTART // Since SDK 3 this might be all obsolete
    parentFound = false;
    devInfoBlock.panID = JDLLC_INVALID_PAN;
    ApiMac_secDeleteDevice(&devInfoBlock.coordExtAddr);
    Jdllc_join();
#endif
//_____________MY CHANGE END____________
}

So in my scenario, orphan phase is skipped and the sensor immediately disconnects from the network after 2 failed transmissions. This works all fine as described in my first post as long as the sensor is not reset or a power cycles occurs and then disconnects and rejoins the network.

Any idea what can be the reason the sensor does not answer the collector message?

Ok, I tried your changes.

1. Removing "parentFound = false" causes the sensor to never rejoin. Because during disconnection, the case if(pData->status == ApiMac_status_success) is never true, because the sensor only disconnects if there is no answering collector anymore. So all the code within this case loop is never executed in my scenario, thus I have to set parentFound = false by myself.
2. Replacing Jdllc_join(); with Util_setEvetn... works the same as before unfortunately no improvement.

I still got no clue why the sensor is not responding to the collector messages anymore...what can be a reason for the sensor to acknowledge the collector reply but not enter dataIndCB() in sensor.c??

kind regards

Slev1n

Are you able to replicate this behavior with the default example and minimal changes?  If so then please provide clear replication steps.  Are only the configuration and tracking messages affected?  Does MAC_CbackEvent send a message to the application for the case MAC_MCPS_DATA_IND which then gets further processed in processIncomingICallMsg?

Regards,
Ryan

Yes, I can replicate this behavior with the default example.

Changes:

1. Channel set to 0 and PHY_ID to ETSI long range mode
2. Skip orphan mode and directly disassociate using Jdllc_sendDisassociationRequest(); in the "else" loop in handleMaxDataFail();
3. To enable automatic rejoin after disassociation I added the following at the end of dissasocCnfCb()

parentFound = false;
devInfoBlock.panID = JDLLC_INVALID_PAN;
ApiMac_secDeleteDevice(&devInfoBlock.coordExtAddr);
Jdllc_join();

That are basically all changes (except for different reporting, polling, tracking intervals and some printouts)

How to proceed

• Establish a working network like described here

http://dev.ti.com/tirex/content/simplelink_academy_cc13x0sdk_1_14_02_04/modules/154-stack_01_sensor_collector/154-stack_01_sensor_collector.html

• Press reset button on sensor board
• perform factory reset on collector board and unplug the board so the sensor will eventually disconnect
• Replug the collector board...the sensor will join and send data messages, but will not respond to config request or tracking requests anymore

Ryan Brown1 said:

Are only the configuration and tracking messages affected?

I think yes. But there are no other messages coming from the collector as far as I know...As you can see in the sniffer log from my first post. The sensor requests data, the collector sends data which is acknowledged by the sensor. Now, the sensor should actually perform the configuration request or tracking request and respond to the collector. But the sensor is doing nothing, in the applications it looks like no message from the collector has ever been arrived.

Ryan Brown1 said:

Does MAC_CbackEvent send a message to the application for the case MAC_MCPS_DATA_IND which then gets further processed in processIncomingICallMsg?

I am not completely sure what you mean, but I put a print statement into processIncomingICallMSG but only in the case for MAC_MCPS_DATA_IND. This works at the beginning, but after performing the steps I mentioned this case is not entered anymore since no messages are printed anymore. So it looks like the sensor is somekind of rejecting/ignoring the messages from the collector at this point.

So, I dont think this issue has something to do with my disassociation procedure. Only if the sensor was reset or unplugged and then disconnects and rejoins this issue occurs.

I can send you my project files from the only slightly changed project_zero example if you want. Are you not able to reproduce the error I am facing?

kind regards

Slev1n

It looks like that it is now working with the basic example, though I have to add parentFound = false at the end of dissasocCnfCb, too.. So maybe it has something to do what I am doing in dissasocCnfCb in my actual code. I will test this with my actual code and report back.

But one question remains. If there is no collector, when the sensor is sending its disassociation request this if loop if(pData->status == ApiMac_status_success) is not entered in dissasocCnfCb() right? I tested it with a print command...it is not in my case. So all the /* set devInfoBlock back to defaults */ is not happening, right? And parentFound is not set to false...Any comment on that pls.

Without a coordinator to provide an ACK the disassoCnfCb status will be ApiMac_status_noAck.  To force these actions to take place you can remove the if statement but the coordinator won't realize that the sensor has been disassociated when it powers back on.  You can also take action in jdllcDisassocCnfCb from sensor.c which is called by pJdllcCallbacksCopy->pDisassocCnfCb(&pData->deviceAddress.addr.extAddr, pData->status); as this function already uses Ssf_clearNetworkInfo to clear NV information and prepare the sensor to associate again.

Regards,
Ryan

I am aware, that the collector wont realize that. However, there are two scenarios, where the sensors will disassociate due to HandleMaxDataFail

1. The collector is replaced, factory reset or flashed so in either of these options the collector does not know the sensor anymore and is not interested in receiving/processing the disassoc message from the sensor.

2. The collector was just too busy or for whatever reason did not answer a few subsequent messages and HandleMaxDataFail() is called. Now the collector might notice the disassoc message but maybe not. E.g. the collector has no power for some time and after the disconnection of the sensor gets powered on again. The sensor will now rejoin and the collector detects a "rejoin" instead of a "new device join".

I have to test the second scenario, but hopefully polling/tracking will still work. Though I still dont know what exactly was wrong with my code I mark your answer as "This resolved my issue" because it must have something to do with my code. I will post updates here or create a new thread if I was able to track the issue further down.

Regards

Slev1n

Glad to hear that you resolved your issue.  Inside of jdllcJoinedCb, Jdllc_addSecDevice is only called if rejoining is false so you were correct in resetting this variable.  This is the only location in which that value is actually used so I do not foresee any negative implications.

Regards,
Ryan