Open Mesh radio_signal_callback busy loop

RE: Open Mesh radio_signal_callback busy loop

Hung Bui — Tue, 02 May 2017 15:13:09 GMT

Hi Pete, How often do you have BLE activity in your application ? I did a test here and count the number of NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_SUCCEEDED multiply by TIMESLOT_SLOT_EXTEND_LENGTH_US I get exactly the size of the time slot I have (usually it's the advertising interval minus a few milliseconds).

So what happens is that we try to request as quick as possible maximum size for the timeslot but requesting each time TIMESLOT_SLOT_EXTEND_LENGTH_US and request again when we get approved (NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_SUCCEEDED event). After that the CPU won't be waken up again to do extending.

If you comment out the line you mentioned, we only request extension when we start a timeslot. This result in 19ms timeslot as you have seen (not sure why it's not 20ms).

We would suggest you to increase TIMESLOT_SLOT_EXTEND_LENGTH_US to 50 or 100ms, then the number of NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_SUCCEEDED will be reduced and you should see shorter period where the PIN_IN_CB is toggled.

RE: Open Mesh radio_signal_callback busy loop

Pete — Fri, 28 Apr 2017 13:41:21 GMT

I don't think changing TIMESLOT_SLOT_EXTEND_LENGTH_US would have an effect, since the busy loop is already a much faster cycle than that. It looks to me like the callback is trying to extend the timeslot immediately after every callback that indicates the timeslot was successfully extended. So I would expect a busy loop. Shouldn't the timeslot only be extended after some delay?

RE: Open Mesh radio_signal_callback busy loop

Hung Bui — Fri, 28 Apr 2017 11:12:00 GMT

Hi Pete,

I can see the same issue here. We will investigate further. One thing you can change is to increase TIMESLOT_SLOT_EXTEND_LENGTH_US and see if it would occurs less often. Commenting out the extending code is not recommended. We will check why there is such a long busy loop.

19ms maybe is the result of 10ms initial timeslot and 01 extension, just my guess.

RE: Open Mesh radio_signal_callback busy loop

Pete — Wed, 26 Apr 2017 14:59:45 GMT

Commenting out this: github.com/.../timeslot.c seems to fix the busy loop, and the mesh still renews the timeslot. I'll continue to see if I have other side effects from commenting that out. The only other thing that is weird is that it seems like the timeslots are 19ms in length, when I would expect 10ms since m_ret_param.params.extend.length_us is set to 10000.

RE: Open Mesh radio_signal_callback busy loop

Pete — Wed, 26 Apr 2017 14:43:45 GMT

I have made changes to the library, but they're restricted to handling additional serial commands, that I wouldn't expect to change timeslot behavior. I think the only unusual thing I'm doing is starting and stopping the mesh periodically.

RE: Open Mesh radio_signal_callback busy loop

Pete — Wed, 26 Apr 2017 14:41:21 GMT

The callback is made at a rate of 15khz, or around 66us between each call.

RE: Open Mesh radio_signal_callback busy loop

Pete — Wed, 26 Apr 2017 14:38:00 GMT

So it appears that we're in a loop of responding to a message that the extend succeeded, and we turn around and ask for another extension immediately. How is this code supposed to work?

github.com/.../timeslot.c

RE: Open Mesh radio_signal_callback busy loop

Hung Bui — Wed, 26 Apr 2017 11:27:49 GMT

@Pete: Could you send the trace ? I want to see the period between the pulses. As far as I understand the timeslot manager only send extend request at the end of the current timeslot with 10ms extension (TIMESLOT_SLOT_EXTEND_LENGTH_US) . It should not be a continuous requests as in your trace. Have you modified anything else in the rbc library ?

RE: Open Mesh radio_signal_callback busy loop

Pete — Tue, 25 Apr 2017 22:15:20 GMT

Looks like NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_SUCCEEDED is the signal being sent to radio_signal_callback(). When I toggle a pin in that case statement, I see frequent toggling during that period.