CSL Tx frame is sent too early

[testter2]

Hi,

I'm testing the CSL transmitter with LP 5.3.3 test case with a radio platform that supports the OT_RADIO_CAPS_TRANSMIT_TIMING capability. While the child update responses are sometimes transmitted at the correct time but I've noticed that in some cases the response is sent too early as in below capture.

When processing a child update request with a 2468 CSL phase then child update response should be sent after 396000 us while it's sent after
14544 us as in previous capture.

Debug Observation : I can see child update response is passed to radio layer with (mTxDelay and mTxDelayBaseTime) equals to zero as In PerformNextOperation, the condition:
if (IsPending(kOperationTransmitDataCsl) && TimerMilli::GetNow() >= mCslTxFireTime)
is not met because the current time is still less than mCslTxFireTime. As a result, the packet is sent via kOperationTransmitDataIndirect too early.

Please correct me if I'm wrong for process of sending frame at specific time

1. The MAC layer requests the CSL Tx Scheduler to prepare the frame.
2. Once prepared, the MAC hands the frame to the SubMac close to its transmission time.
3. The exact timing is managed by the radio platform.

So As mCslTxFireTime timer not fired yet, then CSL frame shouldn't be passed from MAC so Sub-MAC, right ?

Is there any reason to send child update response frame using kOperationTransmitDataIndirect but not kOperationTransmitDataCsl ?

Thanks

[abtink]

kOperationTransmitDataIndirect is used when the child sends a "data poll" (data request frame) asking for the frame. This is most likely the reason for behavior you are observing.

If there is no data poll from the child, then CSL will be used (waiting for the window to tx).

[testter2]

Thanks for the explanation. Based on your response, I suspect that setting the frame pending flag to true in the ACK for the child update request might be prompting the child to send a data poll, which then triggers the use of kOperationTransmitDataIndirect.

Based on this commit of reversing extended address
[radio] reverse extended address in radio layer

It seems like remove address reversing from SourceMatchController::ClearEntry(Child &aChild) API is leading to reversed address passed to otPlatRadioClearSrcMatchExtEntry API so frame isn't removed from radio platform perspective and this leads for frame pending to be set to Ture while there's no frames pending .

Is this behavior expected ?

[testter2]

@abtink @jwhui As mentioned in above comment, I confirm that the address passed to otPlatRadioClearSrcMatchExtEntry is in big-endian byte order, which does not match the API description that expects little-endian byte order. Should the API description be updated or there's fix added for previously mentioned commit ?

[abtink]

Thanks @testter2 for reporting this (sorry I missed your earlier comment).

This seems to be indeed a bug introduced in #10892 where while Radio::AddSrcMatchExtEntry() was updated to reverse the byte order, the Radio::ClearSrcMatchExtEntry() remained unchanged.

I will submit a fix for this soon.

[abtink]

Submitted

• [radio] fix ClearSrcMatchExtEntry() Extended Address byte order #11257

[testter2]

Thank You, It's working fine now.