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

nRF52 heart rate Bluetooth not working

Hello everyone,

The more I learn, the more I learn how much more I have to learn.

I am pretty new to embedded systems development. I am tasked with developing an nRF52-based Bluetooth device. I have successfully compiled and run many non-Bluetooth programs which send data over the UART. So far, I have had no luck getting my PCA10036 nRF52 development kit seen by other Bluetooth devices (an Apple laptop, an Android phone). My boss says that communicating between devices made by different manufacturers is sometimes challenging.

However, I just acquired a second PCA10036. If I understand the SDK 0.9.1 documentation, I have what I need to try the ble_app_heart_c example. I don't care about the heart rate service specifically, but at least I should be able to verify that Bluetooth is functioning, in a Nordic-to-Nordic connection. I am still not getting it to work.

My problems may be no different than the ones I described in an earlier question, but then again, they might be. I use JLink, on a Linux box. Here is what I have done:

  1. I flash the S132 SoftDevice .hex file to both boards at memory address 0.
  2. At memory address 0x1f000, I flash ble_app_hrs_c to one board; then I connect a UART to it.
  3. At 0x1f000, I flash ble_app_hrs to the other board.

Nothing ever happens. My UART remains silent. The SDK asks you to observe on the "central" device "that the BSP_INDICATE_ADVERTISING state is indicated." On some older boards, there's apparently a blinking LED state associated with advertising? On the PCA10036, I'm seeing no Blinkenlights when I run the heart rate apps.

In the discussion I mentioned above, I was beginning to believe that the S132 driver was not handing off control to my application at 0x1f000 as it should. I don't know why that might happen, or how to determine whether it is happening. But my new result is consistent with the earlier result.

Any suggestions? Thanks.

  • I don't know if anyone is still following this discussion, but I discovered the solution to my problem. If the application code is flashed BEFORE the SoftDevice, everything works! In other words: step 1 from the above procedure becomes step 3.

    When all this is done, there are indeed Blinkenlights, and simulated data is transferred over the Bluetooth link.

    This makes me wonder exactly how memory is being erased by JLink. Is JLink's default procedure to erase every memory address from the highest address needed by the program, down to 0? When I had the order reversed, it is possible that I was just erasing the SoftDevice after loading it.

    My development platform is Linux-based. Until recently, nrfjprog was apparently unavailable on Linux. I just downloaded the Linux version of nrfjprog, and I now will try it. I was unable to use the Nordic makefiles to flash the board without nrfjprog. Loading order may be unimportant when nrfjprog is used, because I can see in the makefile that specific ranges of memory are selected for erasure. I do not specify the erased memory range when using JLink -- indeed, I don't know whether it's even possible. Time to RTFM.

  • Hi

    Do you have different experience with nrfjprog for linux? Is it working now as expected?

Related