BLE Application with Soft device has nondeterministic operation

[Jamie]

Hi,

I've developed an application which sends sensor data through the BLE interface at maximum available bandwidth by checking the BLE_ERROR_NO_TX_BUFFERS return value.

During development, I've run into (and currently still see) some very strange non-determinism in the application's operation in different executions of the exact same firmware (without reprogramming). See below for some examples:

• Upon boot, BLE advertising is started. Device can be either discoverable, or not.
• Upon first disconnection (using either Android or MCP), device is either discoverable, or not.
• Upon a connection, device is either sending data at high rate, or not at all. (this one is the most common of the three).

Please keep in mind that the above differences in operation come from the very same firmware binary. I suspect the Soft device is somehow overrun with data sends, or is corruptible. What might be the cause, and what can I try to arrive at a solution in an efficient manner?

Thanks, Jamie

[Ole Morten]

This is not common behavior. There was a bug with softdevices between 5.0.0 and 5.2.0 causing advertising to potentially stop for periods under certain environmental conditions, but this was fixed in 5.2.1, so I'd recommend you to verify that's the one you're using with regard to the advertising issues you see.

As for the latter, I don't have any good direct suggestions on what might be wrong, but you should make sure that you check error codes on all softdevice function calls. For development I'd also recommend you to make sure that your app_error_handler does not contain a reset, but instead an infinite loop, so that you can easily catch errors if you have any.

If you can supply a complete project showing any of these problems, I'd be happy to take a closer look.

[Jamie]

Hi Ole,

I'd be happy to forward you the project through email or otherwise, but I'm afraid it relies on interrupts generated by hardware that you won't have on your side (data is being generated there, which I sample and send at high rates through BLE). I should also mention that if I turn down the BLE connection interval to 1000 ms, for example, the problem almost completely disappears, so it is highly tied to the BLE bandwidth.

I was thinking about inserting some delays to start application (BLE handler) timers until some time after the connection completes, as I am currently activating them when the connection is made in the BLE handler.

Also, I noticed that some code called by application_timers_start() in the SDK might have an issue as this is called in the SDK example after the Soft Device is enabled. The code in question does not use the sd_nvic_* functions, but instead uses the NVIC_* functions supplied by CMSIS. I tried updating this code to use the sd_nvic_* api, but noticed no change in behavior.

Best, Jamie

[Jamie]

BTW, I have been using v5.2.1.

[Ole Morten]

Even though it relies on custom hardware, it might be useful to get a look on the code. Again, if you need confidentiality feel free to create a support case.

Also, did you check app_error_handler?

Actually, if you just make sure you don't violate any rules, there isn't any problems with not using sd_nvic_*, it's just about making sure that doing illegal things will be impossible.