This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Is there any possible interference between the ble advertising service and the timeslots api?

We're​ developing with SDK 10.0, nrf51, softdevice 8.0.0, s110.

We started with the ble_uart_app and added our own functionality, which includes the timeslot functionality. It's supposed to reserve a slot every 8ms, for 1.5ms, but it's a best effort. If we don't get it, we simply skip that slot and reserve the next. The timeslot doesn't actually do anything yet, it's just idle. Sets up the timer0 and ends when it's supposed to.

We developed an android app, again based on the uart_app code, to communicate with our system. That works well enough, no real issues. But I found that if I try to pair to the device using a regular Android interface, the pairing is refused (expected) but it causes the chip to just lock up somewhere. Since we have a watchdog, it resets, but it's a problem.

The on_ble_evt is based on the uart_app example. I found that adding a sd_ble_gap_disconnect() in the case BLE_GAP_EVT_AUTH_STATUS: fixes the resetting from Android connection problem.

Attempting to connect from Android is refused, and the chip runs fine. I can try all day. Connecting to our app is also good, I can​ connect and disconnect as many times as I want. But if I try to connect from Android and then after that connect using our app, it freezes up in the same manner.

It seems to happen once the ble_advertising is supposed to start again after a terminated connection.

Removing the timeslot seems to alleviate the issue. Maybe it's just my imagination, or they are unrelated. I checked the ram usage, that seemed fine. We have over 1kB free whenever we watermark check it.

Since we had to spin a custom board, it's been a hassle to debug it, and even the code is modified enough that I'd have to change it quite a bit to build in the current Nordic framework. We use Scons.

Any suggestions on what to try?

Edit: Sniffing_Android_then_app3.pcapng Wireshark trace of BLE traffic. Around packet # 304 the app is trying to connect, which triggers reset.

Related