Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

pca10028 disconnects immediately when trying to connect using ble_app_uart

Can anyone tell me if there is a specific problem on the nFR 51 using the 12.3 DK, where a disconnect is seen when it connects? I'm using Android Lolipop 5.0 on a BLU device. I see the disconnect immediately after selecting the nordic device in the selection dropdown, so it does see the device.

I have read that the 51 had problems, and it wasn't clear if the 52 also has the same problem, or if this is similar with a timeout not being set at the start?

The project I'm working on will use the 52 and I'm thinking of just buying one, but before I do I wanted to find out if this is a common problem with 51 and 52 devices? Isolated to 51? Neither, an error in the ble_app_uart example?

I'm going to get the sniffer setup tonight and see what I see, but I'm using Linux so it requires some jumping through a couple hoops to get the nRF sniffer going...:(

Any help would be appreciated. Eventually I need to get a 52 board, but was trying to use this until the firmware iscomplete, that will be based around your 52 chipset. I'm not doing that portion, I'm on the software side.

The firmware engineer is on vacation, so I'm trying to get going in the meantime. AFAIK, I have the example built and flashed properly to the pca10028 device I'm using.

I'm attempting to use the UART profile with 32 bytes of data.

Compiler:
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

flash:
[aland@eagle armgcc]$ pwd
/home/aland/src/nRF5_12.3.0/examples/ble_peripheral/ble_app_uart/pca10028/s130/armgcc
[aland@eagle armgcc]$ make flash
Flashing: _build/nrf51422_xxac.hex
nrfjprog --program _build/nrf51422_xxac.hex -f nrf51 --sectorerase
Parsing hex file.
Erasing page at address 0x1B000.
Erasing page at address 0x1B400.
Erasing page at address 0x1B800.
Erasing page at address 0x1BC00.
Erasing page at address 0x1C000.
Erasing page at address 0x1C400.
Erasing page at address 0x1C800.
Erasing page at address 0x1CC00.
Erasing page at address 0x1D000.
Erasing page at address 0x1D400.
Erasing page at address 0x1D800.
Erasing page at address 0x1DC00.
Erasing page at address 0x1E000.
Erasing page at address 0x1E400.
Erasing page at address 0x1E800.
Erasing page at address 0x1EC00.
Erasing page at address 0x1F000.
Erasing page at address 0x1F400.
Erasing page at address 0x1F800.
Erasing page at address 0x1FC00.
Erasing page at address 0x20000.
Erasing page at address 0x20400.
Erasing page at address 0x20800.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
nrfjprog --reset -f nrf51
Applying system reset.
Run.

OS:
Ubuntu 18.04 (bionic beaver)

Alan

Parents
  • Hello,

    There was a "bug" in the softdevice (both s132 and s130) which caused a disconnect with some Android phones. This "bug" was fixed in S132 v.3.1.0, but was unfortunately never fixed for the S130 for the nRF51.

     

    The bug was not actually a bug. It was caused by some Android phones not following the BLE specification, sending two Link Layer requests in parallel. The bugfix is just allowing this to happen, even though it is outside the spec.

     

    If you get a sniffer up and running (you can use the nRF Sniffer), and you see that there are two LL messages without a response from the nRF between them right before the disconnect, this is probably the issue.

     

    You can try to use another phone, if you want to get started with the development on an nRF51, but if you have an nRF52 DK, I would recommend you to start directly on that.

    You should not see this if you use s132 v3.1.0 or later. But if you start the development now, I recommend you to go with the latest SDK, SDK15.1.0, and the latest softdevice, S132 v6.0.1. Note that it is not the version that is included in the SDK. It should be compatible with SDK15.0.0, but it has prequalified advertising with Long Range and 2Mbps, as well as some minor bug fixes. 

     

    Best regards,

    Edvin

  • Edvin,

    Can you tell me if Nordic keeps a list of devices vs. Android release and/or Android Device?

    I'm not trying to trick you, and know the problem with working with so many Android devices. Primarily I need to know what what devices I will declare my software will run on.

    I haven't worked on Android in several years, but I imagine it's only gotten worse. I've heard there are companies that specialize in testing, where they would test your application on various Android releases and on most of the popular devices (phones/tablets).

    Does Nordic publish any type of list showing any of your devices on various levels of Android?

    My understanding is that Android 4.3 is needed for BLE, but the problem for engineers is knowing which releases and/or which hardware might have problems. In a way it's good for me to see this problem now, I know Android support isn't easy with so many devices, and want to prepare myself should this project get that far.

    Cheers,

    Alan

  • Hello Alan,

    Unfortunately, we do not have this type of list. The thumb rule, My understanding is that the earliest android versions that supported BLE was a bit unstable. I believe this was 4."something", so 4.3 might be unstable for some phones. So if you try a phone from the later years, it should be more stable.

     

    However, I can't guarantee that this is actually the issue. You must check the sniffer log. However, there are no known issues with the common examples in the SDK (the ones not marked as experimental) with relatively new phones (both Android and Apple).

     

    You can post in this thread when you receive the nRF52DK, or if you have any other questions before that.

     

    Best regards,

    Edvin

Reply
  • Hello Alan,

    Unfortunately, we do not have this type of list. The thumb rule, My understanding is that the earliest android versions that supported BLE was a bit unstable. I believe this was 4."something", so 4.3 might be unstable for some phones. So if you try a phone from the later years, it should be more stable.

     

    However, I can't guarantee that this is actually the issue. You must check the sniffer log. However, there are no known issues with the common examples in the SDK (the ones not marked as experimental) with relatively new phones (both Android and Apple).

     

    You can post in this thread when you receive the nRF52DK, or if you have any other questions before that.

     

    Best regards,

    Edvin

Children
No Data
Related