LAUNCHXL-CC1310: Error code 235 during in assocCnfCb()

Hi,

I' not sure why this happens. Can you do a test with our most recent SDK?

I think if you want to understand why there is an error just on one side I would recommend making a sniffer log.

Ok, I will try to find some time to go into more details.

Part Number: LAUNCHXL-CC1310

Hey guys,

I am referring to a closed thread (https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/sub-1-ghz-forum/980109/launchxl-cc1310-error-code-235-during-in-assoccnfcb) where I noticed a strange behavior (only in FH mode) during the final association steps. Following Marie H advice I used the sniffer to gain more insights, however, I DID NOT USE THE LATEST SDK. Implementing all my modifications would be too much work as I am quite sure that this behavior is occuring with the latest SDK as well (but is only an assumption).

On the sensor side, I noticed two error states I need explanation for, since they are not explained or part of ApiMac_assocStatus_t.

1. If I prevent the collector to send an association response, the status in assocCnfCb() is 233 (not defined in ApiMac_assocStatus_t)
2. Sometimes occuring using my general firmware but also reproducible if RX_ON_IDLE is set to TRUE before calling sendAssocReq() the error status is 235.

Both status states are not defined but somehow returned from the stack by calling pData->status.

A few further observations I made:

• Case 2 is not occuring if only ONE channel is used in FH mode
• After about 20-30 association attempts, the sensor was able to join the collector with RX_ON_IDLE set to TRUE before calling sendAssocReq()
• The assocResp status transmitted by the collector is always 0
• Using 60 different channels, I was able to log the association response step after some time in the sniffer. I could see that on one channel (in this case channel 100) the collector Acknowledged a data request from the sensor followed by an associaton response from the collector, however, this response was never acknowledged by the sensor. Besides, I assume this step was proceded by an acknowledged association request, which must have been transmitted on another channel. Here a snippet of the log

In my opinion, this is a stack related bug occuring sometimes during association and is related to the sensor not listening correctly (either RX is off or wrong channel) for the association response. I am very sure it is a bug on the sensor side since it is triggered by setting RX_ON_IDLE set to TRUE before calling sendAssocReq().

EDIT: I just walked through api_mac.h searching for 0xEB = 235 and 0xE9 = 233. These status states are used within ApiMac_status_t and mean:

235 = The associate request failed because no associate response was received or the poll request did not return any data

233 = The operation or data request failed because no acknowledgement was received

These states make sense given the test circumstances and sniffer observations, althoug h I dont know why the ApiMac_status_t states are returned and not the ApiMac_assocStatus_t. However, I want to know why the sensor is not receiving the association request. RX_ON_IDLE set to TRUE before calling sendAssocReq() trigger is, but WHY? Moreover, without setting this, it sometimes occurs, too, and is quite persistent. But it never occurs if only ONE channel is used in FH.

I hope you can provide me some thoughts on that.

best wishes

Slev1n

Hi, 

I unlocked the original thread and merged it.

The error codes you are seeing are defined as part of ApiMac_status_t in api_mac.h.

    /*!
     The associate request failed because no associate response was received
     or the poll request did not return any data
     */
    ApiMac_status_noData = 0xEB,

    /*!
     The operation or data request failed because no
     acknowledgement was received
     */
    ApiMac_status_noAck = 0xE9,

Marie H said:

The error codes you are seeing are defined as part of ApiMac_status_t in api_mac.h.

That is correct.

However, could you try to reproduce this issue, either with the most recent SDK or 3.1? I assume there is some timing or channel issue causing the sensor to either not listen or being listening on the wrong channel. But I think this is only accessible via the stack.

best wishes

slev1n

Hi,

I will look into reproducing this issue, however I don't think I will have time before easter so it may take a while. 

Can you please take a sensor + collector example from the SDK, make the code change (set FH mode + set ApiMac_attribute_RxOnWhenIdle to true) and verify that you are able to reproduce the issue?

Hi Marie, I will try to find time to verify this next week.

Hi Marie,

I used the 3.1 SDK of the sensor example for CC1310. I simply added the RxOnWhenIdle to true right before transmitting the association request and I was able to reproduce the error. I receive the status 235 in the assocCnfCb() function.

Again, I assume the sensor does not receive the Association response and thus does not acknowledge it leading to an association fail.

I was so curious, so I installed all the stuff necessary for the 4.1 SDK and tested again with a clean code sample. As expected, the same behavior. There must be something inside the stack not liking to activate RxOnWhenIdle before sending the assoc request...

But I really want to know what the problem is because I sometimes receive the same error in other scenarios (though not reproducible).

Best wishes

Slev1n

Hi,

Ok thank you for doing the test. I will get back to you when I have been able to reproduce.

Hey Marie,

I was wondering if you already had time to look into this issue?

Thank you for your feedback Marie. However, I have to disagree, that the Stack handles RxOnWhenIdle properly if in FH mode. At least if you need low power consumption prior to network association on the sensor side. Therefore, exploiting the application-stack-API functionality to set RxOnWhenIdle to true/false should be possible whenever needed. I certainly regard this as a bug and suggest an update in a following SDK.

best wishes

Slev1n

Hi Marle:

I have met the same problem with Slev1n, and I use the latest SDK(4.10), FH mode, I didn't set the RxOnWhenIdle directly but contfigure the sensor as a non-sleepy device. Now the sensor also received the status 235 in the assocCnfCb(). Otherwise, for the collector, assocRsp.status in ApiMac_mlmeAssociateRsp is 0(ApiMac_assocStatus_success),  in commStatusIndCB, the pCommStatusInd->reason=0, pCommStatusInd->status=0xF0

I am stuck in this problem for sevral days, apriciate for your reply as soon as possible.

Hi Jing,

Can you post a sniffer log from this situation?

My debug Info:

for sensor:

TI Sensor
Jdllc_join: Jdllc_states_joining
State Changed: 1

SEND PAS PASintv=6000
IN processIncomingICallMsg evnt=17

SEND PAS PASintv=6000
IN processIncomingICallMsg evnt=17

IN processIncomingICallMsg evnt=18
In wsAsyncIndCb：status=0x0 pData->fhFrameType=0x0(panAdvert)

wisunPiePresent=0x3 parentFound=false start PCS clock,Inerval=6000

SEND PCS PASintv=6000
IN processIncomingICallMsg evnt=17

IN processIncomingICallMsg evnt=18
In wsAsyncIndCb：status=0x0 pData->fhFrameType=0x2(config) wisunPiePresent=0xC parentFound=true start assocRsq clock...
processFHAssocTimeoutCallback SET_EVT:ASSOCIATE_REQ_EVT
sendAssocReq
IN processIncomingICallMsg evnt=2
IN assocCnfCb status=0xEB fhconfigIntv=6000 change:parentFound=false

IN processIncomingICallMsg evnt=13 dataIndCB Jdllc_events=1
ProcessConfigRsq: repItv=3000 polItv=1000 send ConfigRsp...

Sensor send msg!!! type=0x2 Addrmode=3 len=13

IN processIncomingICallMsg evnt=12
IN dataCnfCB: status=0xE9

IN processIncomingICallMsg evnt=13 dataIndCB Jdllc_events=3

Sensor send msg!!! type=0x4 Addrmode=3 len=1

IN processIncomingICallMsg evnt=12
IN dataCnfCB: status=0xE9

processFHAssocTimeoutCallback SET_EVT:ASSOCIATE_REQ_EVT
sendAssocReq
IN processIncomingICallMsg evnt=13 dataIndCB Jdllc_events=1
ProcessConfigRsq: repItv=3000 polItv=1000 send ConfigRsp...

Sensor send msg!!! type=0x2 Addrmode=3 len=13

IN processIncomingICallMsg evnt=12
IN dataCnfCB: status=0x19

IN processIncomingICallMsg evnt=2
IN assocCnfCb s=0xEB fhconfigIntv=6000 change:parentFound=false

IN processIncomingICallMsg evnt=13 dataIndCB Jdllc_events=3

Sensor send msg!!! type=0x4 Addrmode=3 len=1

Cause  dataCnfCB: status=0xE9, sensor had to  sendAssocReq again and again....

for collector:

TI Collector
IN Collector_process: EVT=0x1

IN cllcStateChangedCB cllcState=0x1
cllcStartedCB panID=0x1 shrtAddr=AABB restarted=0 Started Freq. Hopping
PermitJoin-ON

IN cllcStateChangedCB cllcState=0x5
IN Cllc_setJoinPermit allowed! joinDuration=0 SetTrackingClock:trackingT=3000

IN cllcStateChangedCB cllcState=0x3
SEND PC PCintv=3000
SEND PA PAintv=3000
IN Collector_process: EVT=0x2
COLLECT_EVT: TRACKING_EVT
SetTrackingClock trackingT=3000
IN Collector_process: EVT=0x2
COLLECT_EVT: TRACKING_EVT

SetTrackingClock trackingT=3000
IN Collector_process: EVT=0x2
COLLECT_EVT: TRACKING_EVT
SetTrackingClock trackingT=3000
SEND Pc PCintv=3000
IN Collector_process: EVT=0x2
COLLECT_EVT: TRACKING_EVT
SetTrackingClock trackingT=3000
IN Collector_process: EVT=0x2

COLLECT_EVT: TRACKING_EVT
SetTrackingClock trackingT=3000
IN assocIndCb.... New deviceJoining addr=1
IN cllcDeviceJoiningCB panID=0x1
Joined: 0x1
status: 0x0 Csf_deviceUpdate status=0x0 setEvent: COLLECTOR_CONFIG_EVT
maintainAssocTable, mode= ADD deviceNum=1
SEND AsscRsp, assoStatus=0
IN Collector_process: EVT=0x4
COLLECT_EVT: CONFIG_EVT
in generateConfigRequests addr-1 s-1
SEND ConfigRequest...

IN　dataCnfCB status=0x0
Update local framecounter new=258 last=258 msduHandle=0xC0 devState=0x101
END da aCnfCB, devState=0x301
IN Collector_process: EVT=0x2
COLLECT_EVT: TRACKING_EVT
SetTrackingClock rxOnWhenIdle=1

IN　dataCnfCB status=0x0
Update local framecounter new=259 last=258 msduHandle=0x81 trackingReqRequestSent=1
IN Collector_process: EVT=0x2
COLLECT_EVT: TRACKING_EVT!Responding: 0x1 status: 0x1301 no trackRsp,clean status,1301 no trackRsp,clean status=,1000 endstatus=,0
SetTrackingClock rxOnWhenIdle=1

IN　dataCnfCB status=0x0
Update local framecounter new=260 last=258 m duHandle=0x82 trackingReqRequestSent=2
IN Collector_process: EVT=0x4
COLLECT_EVT: CONFIG_EVT
IN Collector_process: EVT=0x2
COLLECT_EVT: TRACKING_EVT
SetTrackingClock trackingT=3000
IN assocIndCb.... assocState= success !!!
IN cllcDeviceJoiningCB panID=0x1
Re-Joined: 0x1
status: 0x0 Csf_deviceUpdate status=0x0 setEvent: COLLECTOR_CONFIG_EVT
SEND AsscRsp, assoStatus=0
IN Collector_process: EVT=0x4
COLLECT_EVT: CONFIG_EVT

IN commStatusIndCB reason=0x0 s=0xF0
IN Collector_p ocess: EVT=0x2
COLLECT_EVT: TRACKING_EVT!Responding: 0x1 status: 0x1001 no trackRsp,clean status,1001 no trackRsp,clean status=,1000 endstatus=,0
SetTrackingClock rxOnWhenIdle=1

IN　dataCnfCB status=0x0
Update local framecounter new=261 last=258 msduHandle=0x83 trackingReqRequestSent=3
IN Collector_process: EVT=0x4
COLLECT_EVT: CONFIG_EVT
IN Collector_process: EVT=0x2
COLLECT_EVT: TRACKING_EVT

Hi Jing,

Thank you for posting the log. It seems like several packets are missed or not ack'ed. Can you use a packet sniffer to see if these packets are going over the air?

How is the RF noise level in your environment? Is it possible packets are being missed because of noise?

Hi Marie:

I have abandoned the test project and import the sensor/collector example to test the fh mode,now the sensor can successfully associate the network.The new question is:

1. The sensor seems cannot detect the network's state while the collector goes wrong(stuck) or power off the collector, sensor's state is always joined(Jdllc_states_joined or Jdllc_states_rejoined). How does the sensor detect the network's state in FH (non-sleepy) mode after the sensor joined the network?

2. What is the frame type of "MAC Data Poll"? Does this procedure means device need to send "MAC Data Poll" periodly as the heartbeat package to the the coordinator know it is online, and the device also can detect the network's state acoording to the "MAC ACK"？