CC1352R: EasyLink_transmit() blocks

I am allocating the EasyLink_TxPacket structure on the stack as follows:

EasyLink_TxPacket txPacket =  { {0}, 0, 0, {0} };

I am also explicitly setting the absTime field to zero again, just to be sure.

Because this is an ack type operation, I am firing off 3 EasyLink_transmit()'s back to back. My understanding is that EasyLink_transmit() should block until complete, so there is no possibility of trying to TX over an existing operation. That doesn't mean that the BLE side isnt doing something... but I think the DMM should handle scheduling in that case?

I am pretty certain the BLE state is unconnected (just advertising), as this happens when I leave the system unattended overnight.

I do not have any explicit delay between my 3 tx's, but I am going to try that now.

I am wrapping that tx block in:

DMMPolicy_updateStackState(DMMPolicy_StackRole_WsnNode, DMMPOLICY_STACKSTATE_WSNNODE_TX);
...do 3 EasyLink_transmit()'s
DMMPolicy_updateStackState(DMMPolicy_StackRole_WsnNode, DMMPOLICY_STACKSTATE_WSNNODE_SLEEPING);

Where DMMPOLICY_STACKSTATE_WSNNODE_TX is defined with high priority and time critical on the subghz

I am reusing the txPacket for each repeated transmit. I just tried explicitly resetting the absTime to zero between each transmit, just in case EasyLink_transmit() modified it somehow. Same results.

I tried just "EasyLink_cmdPropTx" in the expression view and there's a pNextOp that has a different status. I'm not sure if that helps any:

EASYLINK_API_VERSION "EasyLink-v2.40.02"

Line 155/156 in EasyLink.c:

static rfc_CMD_PROP_TX_t EasyLink_cmdPropTx;
static rfc_CMD_PROP_RX_ADV_t EasyLink_cmdPropRxAdv;

The latest development on my end was to try and wrap the transmit in a HwiP_disable/enable:

        uint32_t key = HwiP_disable();
        EasyLink_Status txstatus = EasyLink_transmit(&txPacket);
        HwiP_restore(key);

That seems to have made the problem go away... but due to the unpredictability of this issue, I cant say for sure, only that it hasn't happened for over 12 hours now, so that's a plus.

My thoughts are that I have an awful lot going on in terms of the DMM and some clocks that fire off to update the characteristics. I am also updating the advertisement bytes, and I do not fully understand what is going on under the hood in those operations (specifically when no BLE device is connected). Is it possible that one of those is indirectly stepping on the transmit and by disabling the Hwi, the transmit operation can run cleanly? (I also don't fully understand the ramifications of the HwiP_disable/enable... I was just trying anything I could think of)

Also, I think I'm going to have to switch to EasyLink_transmitCcaAsync() as my deployment environment is pretty noisy.

This is super frustrating. It happened once with my modifications, but the debugger crapped out. Then I disabled optimizations to fix that breakpoint issue (thanks... a more descriptive error message in CCS beyond the AET text would be helpful). Now its been running for close to 24 hours without an issue.

I'm headed back to the field to test in the noisy environment, so I switched back to the CCA/async code (which doesn't have the event flag / trap you suggested). I'm going to let it run over night and see if something happens. I'll do my field tests, then I'll switch back to the synchronous code and run it over the weekend and hope to catch the error.

My theory at this point is that the optimizations might have caused this particular issue? I don't have any evidence to back that up, but recently I saw a very weird (unrelated) and hard to describe issue on my companion device and that was solved by turning off optimizations (then I turned optimizations back on and that odd behavior inexplicably was still gone... I made no other changes to the code)

My observation here is that compiler optimizations do weird things. Are there any references on that general topic?

Sorry for the delay. I did some field tests last week and came away with more questions than answers...

The CCA code didn't work as I hoped. It appears the environment is particularly noisy and my EasyLink_transmitCcaAsync() calls (in the reverse direction) were mostly busy. That's probably a side note to this main thread. Briefly though, there's a large AC motor in the vicinity and a bunch of 900MHz traffic. None of this is excessive, but its far more than my development environment.

When a packet did manage to transmit (from the remote device) to the board that is having the trouble (this thread), the board locked up. I'm not sure if this is the same issue since I didn't have a debugger. I left the field with very little insight. The board in question acks the packet with a transmit, so I'm not 100% sure where the failure is (on the rx or tx)

Over the weekend I left the system running again and it finally crapped out again. This time however, the stack trace from ROV is a bit different. On deeper inspection of the line numbers and functions listed in the Tasks->CallStacks of ROV, they don't appear to line up with actual lines of code. I have optimizations turned off.

If the ROV callstacks are to be roughly trusted, looking back the the codeline previous to the one listed in ROV, it does appear that it is stalled out in the EasyLink_transmitCcaAsync() call, or possibly on my semaphore waiting for the txcallback to complete (which never got called). It is strange however that my whole program stalls, even the clock I have set to toggle an LED to verify things are running.

My hope at this point is that the issue I was seeing regularly in the field is the same as the one I'm seeing after hours on the desk. My plan is to get CCS running on a laptop and revisit the field to try and trap that error with a bit more clarity. Hopefully that will happen some time this week.

I made it back to the field and uncovered one glaring issue... but I dont think it is the one that is plaguing me in this thread. I migrated my code from an older 1350 project and dont have the TRNG initialization that is in the 1352 examples. Apparently the CCA code has some sort of dependency there. Here is a stack trace:

Incidentally, the other end on a 1310 is running fine with the CCA code without the TRNG initialization.

Can you shed some light on the dependency here? Is it possible that there is some rand() dependency that is surfacing after a certain number of calls? I'd be surprised if these issues are related, but its worth asking.

Hi Spanky,

In the case where pGrnFxn is not passed along the parameters, the default function will be used which is rand(). For your CC1352 device, did you base the EasyLink side on any particular example? I know the "Listen before talk" example uses the TRNG functionality.

Yes, copying/linking that file into the project would override the library version.

My code evolved out of the project_zero example from the 1350, but I integrated the DMM code and the asyncCCA stuff. In the last SDK release, I did a pretty thorough comparison as I though that update might have changed something in the example code.

I'm a bit perplexed why rand() would crash like that, but I don't think that is directly related to the main issue here.

I've been combing over my code to try and figure out what might be the issue. I have a potential bug in an un-handeled event (basically I'm posting an event once a second and not handling it through pend due to an event mask). I put that in another thread because I couldn't find an answer to what happens to unhandled events:

This probably isn't my issue, but after adding the event to the pend mask, it seems to be running for longer than it had previously (I'm up to about 14 hours now, where it used to only run 4ish hours before locking up). Every time I think I've found the issue I've been wrong, so I'm not super optimistic.

It has been running on the debugger for some time now and it did break out on this. I didn't have a breakpoint here, and I've never seen it stop here before. I was able to just hit resume and it seems to have continued on unaffected:

Everytime I "think" I've solved the issue I've been wrong and spoke too soon.... but after resolving that event mask issue, its been running all weekend without issue, which is a massive improvement (aside from that random hiccup on the CPUwfi(), but all I had to do there was resume execution, so I'll chock that up to a random occurrence)

I think there's more to it than just the event mask, because the event I was trying to fire off every second still did what I wanted. I'm not sure how, but I haven't thoroughly investigated yet since I wanted to leave the setup running as long as possible to make sure the locking up went away.

I'll dig in this week to try and make sense of it and report back.

Interesting, looking forward to your report. As for the "WFI" place, it is strange that the debugger stopped you there, but it sound like a hiccup in the debugger (as you said) as this is where you expect to be when the device goes into idle/standby state.

Nice to hear you found the issue, tricky one :)

Good luck with the rest of the development!