NRF_ERROR_DATA_SIZE & sd_ble_evt_get with Streaming Data

[jpelo]

Using nRF52; S132 v4.0.3

I'm getting NRF_ERROR_DATA_SIZE error return from sd_ble_evt_get and event length from call is 20 which is smaller than my buffer so it shouldn't be an event > buffer issue. This started happening with 100Hz update of a 20byte characteristic with notifications enabled. If the update to this characteristic is slowed down, the error goes away.

Is this a matter of me being able to consume events fast enough? What are the additional ways in which sd_ble_evt_get returns NRF_ERROR_DATA_SIZE (besides an event larger than buffer problem)?

[Hung Bui]

It sounds a little bit strange that the function complains about the buffer size when it should not be a problem. Could you make a simple program that can demonstrate the issue ? I assume you have the issue on the central side ?

[jpelo]

Yes definitely strange.

I am a peripheral. I have a data characteristic that is 20bytes that I am updating at 100hz. When the central has subscribed to notifications for this data characteristic is when I get this issue. The issue shows up when the central writes to a different characteristic that is also 20bytes. The streaming at 100hz runs fine (data coming into central without issue). From my central, I can read other characteristics and subscribe to other notifications. But as soon as i write this other 20 byte characteristic, i get the nrf_error_data_size error. When streaming on the data characteristic at a slower speed, I can write to the other 20 byte characteristic without problem/error.

i did see this error come up earlier with slow connection parameters and quickly toggling subscribe/unsubscribe (rapid mouse click subscribe/unsubscribe on central). volume of events?

[jpelo]

Fixed this issue; user error. Bug in the way I was looping in the event handler and getting ble events from stack. Problem showed up with more ble traffic because it causes multiple events to be queued up.

[Hung Bui]

Good that you found the solution, but isn't it true we do the same thing in our SDK ? We have a loop in the event handler intern_softdevice_events_execute() to get all the event out. I don't really understand why it could be a problem. Note that if the application failed to pull the event out, the softdevice will start NACKing the peer device.