Open Mesh radio_signal_callback busy loop

[Pete]

I was having some troubles using the app_timer (RTC1) shortly after mesh startup, so I enabled the PIN_IN_CB and PIN_IN_TS debug pins, and saw some interesting behavior.

My app periodically calls rbc_mesh_enable(). On the first enable, it looks like everything is fine, and we're in the timeslot with what looks like random infrequent calls to the callback.

After calling rbc_mesh_disable(), waiting about 100ms ,and then calling rbc_mesh_enable(), there is a period of ~20ms that looks ok, followed by a period of very frequent callbacks to radio_signal_callback that lasts about 66ms. During this time, I do not receive any RTC1 callbacks.

Any ideas what this might be?

[Pete]

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.

[Hung Bui]

@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 ?

[Pete]

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

[Pete]

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

[Pete]

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.