# nRF51 DK won't connect with nRF Toolbox

Hello,

I'm wondering if my nRF DK51 is not broken as it behaves quite strange when trying to connect with a BLE Central (iOS and Android devices). For most of the part everything is ok (flashing, RTT, UART, BLE advertising) but when I try to connect on any of devices it immediately breaks the connection.

Initially I thought that it's an iOS thing since there's a few quirks when changing firmware and GATT for a device with the same MAC address. But the same issue persists on Android which IIRC relies less on caching of GATT.

When trying with ble_app_uartwith nRF5 SDK 11 example on Android logs show the following:

...
Connection state changed with new status: 0 and new state: 2 (CONNECTED)
Connected to [MAC]
Discovering Services...
gatt.discoverServices()
Discovering Services...
gatt.discoverServices()   //Yes, second time
[Callback] Connection state changed with status: 0 and new state: 0 (DISCONNECTED)
Connection lost
Connection state changed with new status: 0 and new state: 2 (CONNECTED)
Connected to [MAC]
Connection state changed with new status: 0 and new state: 2 (CONNECTED)
Connected to [MAC]      //Yes, second time again
Discovering Services...
gatt.discoverServices()
...                     //and so on


I started having issues while running my own custom firmware and initially thought that I was running out of RAM but after some debugging I came back to SDK examples and noticed that the behaviour is the same.

Is there a chance that my nRF51822 on the DK got damaged somehow and could behave in such way?

edit retag close delete

Sort by » oldest newest most voted

My first thought is that the chip is not damaged. There is a risk of ESD damage, but that doesn't happen very often.

If you test one of our examples, place a breakpoint in the error handler, and run the chip in debug mode? Will the error handler be "called"?

more

Hi Kristin,

Thank you for your reply. I've tested today with one of custom boards I've made with nRF51822 and the samples work ok, so most definitely it is something wrong with my DK (which is possible as it's suffered gont through a lot).

With my question I also wanted to rule out the possibility that nRF51822 could potentially have not sufficient amount of RAM to handle a BLE connection. If I understand this correctly, that would be the case for AB variant with 16KB RAM, is that right? I can't seem to fit the app_ble_uart example even after modifying .ld file to correct values for AB variant.

( 2017-03-21 22:05:15 +0200 )editconvert to answer

Okay, I see.

Yes, whether or not the nRF51822-QFAB has sufficient RAM depends on the application. When I compile ble_app_uart in SDK 12.2.0, it uses 4.34 kB RAM.

The minimum required RAM by S130 v.2.0.1 is 4.95 kB, and the ble_app_uart example in the SDK doesn't need to use more than 4.96 kB. So the ble_app_uart will fit in the QFAB version.

(Total flash: 108 kB (softdevice) + 13.23 kB = 121.23 kB)

( 2017-03-22 11:29:13 +0200 )editconvert to answer

[hide preview]

## Recent blog posts

• ### Introducing nRF5 SDK for Mesh

Posted 2017-07-20 09:42:44 by Pär H

Posted 2017-07-19 06:53:42 by Mohammad Afaneh
• ### Unique Thread/Bluetooth multiprotocol solution with nRF5 SDK for Thread and nRF52840 SoC by Nordic

Posted 2017-07-14 10:31:56 by Krzysztof Loska
• ### nRF Connect macros (currently Android only)

Posted 2017-07-14 13:29:14 by Aleksander Nowakowski
• ### Power Optimization — From 3 to 7 Months on a Single Charge

Posted 2017-07-10 14:34:39 by Yaniv Nis

## Recent questions

• ### Real UART TX transmit depth?

Posted 2017-07-22 01:21:21 by samsonc

Posted 2017-07-21 19:11:52 by TravisFS
• ### app_timer_freertos.c/app_timer_stop bug?

Posted 2017-07-21 19:11:15 by loquat
• ### Are there any particular practices or instructions should i follow if I want to write a custom library

Posted 2017-07-21 18:13:10 by binhnguyens
• ### fstorage in chosen area

Posted 2017-07-21 18:02:00 by cedric