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

[KPE]

Well everything seems fine, so it's quite strange. Anyway, I guess that you have already tried a lot of different things, but in a case like this I would probably try the following:

1. Start by figuring out where the "lockups" happen - are we inside the BLE stack, or outside?
2. Remove dependencies to the external HW - stub out the data collecting code, and disable interrupts etc.
3. Make the code as simple as possible (down to just incrementing and send a static counter)
4. Make random delays in various "strategic places" to see if it can lead to a timing issue somewhere
5. Hmmm... check the office against earth radiation, and wear my tin foil hat ;-)

If you can remove the HW dependencies, I'm also ready give your project a spin.

[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.