CC1350: Unexpected Behavior After Collector Restart

CDev

Part Number: CC1350

Hello TI,

Context:

I'm experiencing an issue using the Ti 15.4 stack 4.x SDK. I have 10 sensors deployed to 1 collector. I've setup the collector to clear NV on startup.

In our testing of a power outage, we experience two different behaviors:

Test 1

If the collector is offline long enough for the sensor to transition to orphan, the sensor rejoins and works as expected.

Test 2

If the collector is offline for a short amount of time, the sensor will not initiate orphan scan, but still be in a connected state. Using the sniffer, we observe data requests being sent and ACK'd, but they do not propagate.

Problem:

In the event of a brief outage, we expect the sensors to properly rejoin the network. It is unclear why the collector is ACK'ing, but not processing the messages. From a similar post, https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/t/747639 this may be related to the security settings, where the collector does not have the extended address, failing to decrypt.

Given this:

- Is there a way to detect this state from either the sensor or collector side? The goal being to recover connectivity

- If related to security, where in the code is the security settings that is causing the packet to drop?

over 4 years ago

0 Elin W over 4 years ago

TI__Genius 14845 points

Hi CDev,

Have you made any modifications to the project(s)? If yes, can you reproduce this issue using the default projects?

Which security settings are you using?

Thanks,
Elin

0 CDev over 4 years ago in reply to Elin W

Prodigy 165 points

Hello Elin,

Yes, I have made modifications to the project. I can repro the issue in the default project if the button is pressed to invoke Csf_clearAllNvItems(); I utilize CONFIG_SECURE = 1

I was able to root cause the issue to ApiMac_commStatusReason_rxSecure with ApiMac_status_unavailableKey being the reason. This makes sense, as the sensors are retaining the security information about the previous network.

I resolved this by adding additional code to pollIndCb. This code will disconnect a device that polls if it is not in the device list. Note: this has a side-effect of being issued twice, as the first poll will queue the request, with the next causing the disassociation, and queuing another.

    if (findDevice(&pPollInd->srcAddr) == NULL &&
        pPollInd->srcAddr.addrMode == ApiMac_addrType_short) {
        Cllc_sendDisassociationRequest(addr.addr.shortAddr, false);
    }

Sub-1 GHz

Sub-1 GHz forum

CC1350: Unexpected Behavior After Collector Restart