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]

I have not tested the current firmware thoroughly, but I had a test running for 6-8 hours that was doing nothing but sending packets at high rate (6580 bytes/sec), in a scenario and setup similar to yours. I think I've killed the source code now, as I've been using the same little project for all my experiments, but it was based on the heart rate sensor (hrs) example.

Are you sure that you can disconnect and connect at any time, and also sure that you are not destroying your packet sequencing when this happens. I remember that I listened for connection events and checked the connection state before even trying to enter the send loop.

It sound a little strange that you are seeing these problems, and I don't think it's common. Did you also check this on another board to make sure it's not a HW problem?

What compiler are you using etc. Can you make an example project that demonstrates the problems you describe and upload it here.

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

[Jamie]

Hi KPE,

Thanks for the reply! Once I am correctly sending data, I can maintain that seemingly indefinitely (I ran a test yesterday for 2.5 hours of successful continuous transmission). The problem is many times it won't reach that state. To answer some of your questions:

*** I cannot always connect/disconnect--see original post. *** I am not starting timers driving BLE sends until I receive a connection event in the BLE handler. *** I see this same operation on both eval kit boards as well as my own custom HW. *** I'm using Keil uVision 4 IDE. The only issue with sharing an example code is that it relies on an interrupt generated by external HW. I can try removing that part so that anyone can try it.

Thanks, Jamie