Possible race in NUS service - are there limitation on where to call ble_nus_data_send() from?

RE: Possible race in NUS service - are there limitation on where to call ble_nus_data_send() from?

Simonr — Wed, 20 Feb 2019 08:18:05 GMT

Sorry for the obscure answer. If you want to protect writes to the variable the easiest way would probably be to use a critical region (disable interrupts before updating it and enable them afterwards), like calling the ble_nus_send_data() from an interrupt handler. You could have a look through \components\libraries\atomic\nrf_atomic.h as well to see if any of the operations does what you need, but I'd recommend disabling interrupts.

Best regards,

Simon

RE: Possible race in NUS service - are there limitation on where to call ble_nus_data_send() from?

Boaz — Tue, 19 Feb 2019 15:17:34 GMT

[quote userid="75734" url="~/f/nordic-q-a/43876/possible-race-in-nus-service---are-there-limitation-on-where-to-call-ble_nus_data_send-from/171912"]Do they interrupt each other when the code runs?[/quote]

Probably - the method called from main() runs in application scheduler context (i.e. main context), and is triggered by a timer.

Can you please elaborate on the "use SD interrupt handler"? Do you mean posting the timer event to an SD IRQ?

Alternatively, does nRF have an atomic increment/decrement operation, which does not include disabling all interrupts?

RE: Possible race in NUS service - are there limitation on where to call ble_nus_data_send() from?

Simonr — Tue, 19 Feb 2019 14:01:45 GMT

Hi,

It is difficult for me to tell if this is a race condition or not, but it seems likely. Do they interrupt each other when the code runs? You can use an SD interrupt handler, probably the easiest way.

Best regards,

Simon