iOS nRF Connect not detecting BLE from nRF52840-based boards

[len_]

When running example code which involves BLE on nRF52840-based boards, the devices (which have assigned names in the example code) don't show up on the iOS nRF Connect scanner. Other devices, such as laptops and Bluetooth headphones show up on the scanner, so it is working to some extent.

I uploaded the 'ble_blinky' example from nRF5 SDK onto the SparkFun Pro nRF52840 Mini. I know that nRF5 SDK is not recommended for new designs, however, there isn't good documentation around the use of nRF Connect SDK with the Sparkfun board.

I also tried using the Adafruit Feather nRF52840 Express, uploading the 'controller' example from the Adafruit Bluefruit nRF52 Libraries via the Arduino IDE (1.8.18, because there is a known issue with uploading to this Adafruit board using versions later than 2.0.0).

In both cases, the Serial output indicates the code is running.

Although I'm aware that I haven't used Nordic Semi's own DK, I feel like the above experience indicates an issue with the iOS app, not the hardware.

iOS nRF Connect: version 2.7.11

iPhone: iOS 16.1.1, iPhone 11

[Kenneth]

Hello,

Is there anyone around that have an Android enabled phone that you can use for comparison?

Kenneth

[len_]

Hi, thank you for your reply.

After some further experimentation, I resolved several issues and this is the current state of affairs:

• Adafruit and Sparkfun boards can both connect to iOS nRF Connect when running Bluefruit-based Arduino IDE examples.
• nRF5 SDK 'ble_app_blinky' example (when running on Sparkfun board) hangs during sd_softdevice_enable().

Some other threads on this forum have recommended changing clock source to resolve this, however changing NRF_SDH_CLOCK_LF_SRC from external XTAL to internal RC (with all associated settings) didn't help. Furthermore, the functioning Bluefruit-based code initialises using the external XTAL, and the Sparkfun board definitely has one.

This is a slightly different problem to my original one so let me know if I should raise a different ticket.

[Kenneth]

Hi again,

Normally I would say the problem is that the softdevice is not able to start the LFCLK source yes, but you have tried the internal RC and see the same, so then we need to look elsewhere.

After a bit of searching I can find cases where incorrect memory layout may cause the same symptoms. Make sure the (correct S140) softdevice is programmed, and that the application code is placed after the softdevice. By default this should be setup correctly though, so not sure I understand why this doesn't work.

Kenneth