Openthread: [efr32] radio: assert during data request, unrelated to #5679

[dismirlian]

Note: this assert is unrelated to #5679.

Describe the bug A clear and concise description of what the bug is.
With very heavy traffic, the following assert triggers (line 747):

https://github.com/openthread/openthread/blob/831406ce9055d622a3258a82a1a6ee556530fc49/examples/platforms/efr32mg12/radio.c#L745-L750

To Reproduce Information to reproduce the behavior, including:

1. Git commit id: 831406ce9055d622a3258a82a1a6ee556530fc49
2. IEEE 802.15.4 hardware platform: efr32mg12
3. Build steps: make -f examples/Makefile-efr32mg12 BOARD=BRD4161A
4. Network topology: 1 NCP + 10 SEDs. The bug occurs on the NCP/RCP.

Expected behavior A clear and concise description of what you expected to happen.
No asserts. The queue used to cache the packets sent with FP set is of the same size of the internal metadata FIFO. Quoting RAIL documentation:

Supplementing the receive FIFO used for packet data, the RAIL library also allocates an internal packet metadata FIFO capable of holding up to 16 packets' worth of metadata. An entry in this FIFO is made on every packet completion (successful or not) signaled to the application. If the application calls RAIL_HoldRxPacket() that entry is held along with any of its packet data in the receive FIFO.

Console/log output If applicable, add console/log output to help explain your problem.
None.

Additional context Add any other context about the problem here.
I increased ACKED_WITH_FP_SLOTS to 32, and I haven't seen the problem again, even under heavy traffic. However, I would like to be certain that this is a safe value. Maybe Silabs can shed a light on this?

[romacdon]

@dismirlian - thanks for reporting this issue. We are looking into it.

[suveshpratapa]

@dismirlian Given your testing with 10 sleepy end devices under heavy traffic, I'm inclined to say this value is safe. You can go ahead and submit a PR. We will also revisit our implementation of this sAckedWithFPFifo queue in our PAL soon.

As an aside, I'm curious -- what are the data rates / polling rates in your "heavy traffic" testing?

[dismirlian]

@suveshpratapa thanks for your answer. We haven't seen any issues since we increased ACKED_WITH_FP_SLOTS to 32. However, I still don't understand why we would need to increase this, if the internal FIFO and this FIFO should work in "lockstep".

The "heavy traffic" is 10 sleepy devices doing the following at the same time:

• Firmware download, using CoAP GETs, packet size=256bytes, FW size=~300kB.
• ~30kB buffer upload, using CoAP POSTs, packet size=256bytes, each upload separated ~15s from the next.
• Poll period=188ms

This is of course an artificial scenario, which we are using to stress the network.

Thanks!

[suveshpratapa]

@dismirlian We are also trying to understand why it is not working in lockstep as intended, which is why I asked you the data rates because I'm curious if it's a timing issue in RAIL. We will definitely look into the frame pending implementation in radio.c further. For now, your workaround should be fine.