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

No bluetooth signal detected from nRF5340-DK

I received an nRF5340-DK last week. Today I got the zephyr toolchain configured and working under Linux, and hooked everything up. The "blinky" sample app works fine. The USB cable is connected to the programmer port and the power switch is at the central setting (the one that turns on the green LED next to the JLink chip).

Using the current nRF Connect app on Android (Pixel 4A), I am unable to detect any BT signal from my nRF5340-DK after compiling and flashing any of several bluetooth sample apps, e.g.:

* samples/bluetooth/beacon
* samples/bluetooth/scan_adv
* samples/bluetooth/periodic_adv
* samples/bluetooth/peripheral_hr

I have attempted to flash each of these sample applications, in succession, to each of the following board targets:

* nrf5340dk_nrf5340_cpuapp
* nrf5340dk_nrf5340_cpuappns
* nrf5340dk_nrf5340_cpunet

[Aside: the "getting started" documentation could be a bit clearer about which board target to use, and when, for the audience of people first getting to know the nRF5340 via sample applications. I'm still fuzzy about the deployment considerations and interactions between these targets.]

I have also used the west --recover and west --eraseall options a couple times to unstick the development process.

Conversely, flashing the "samples/bluetooth/periodic_adv" app to my nRF52382-DK via the nrf52dk_nrf52832 board target works fine; I see the bluetooth signal perfectly on my phone.

I have reviewed the online DK specifications and it doesn't seem like there's any DIP switch that disables RF, so I'm stumped. Do I have a defective unit? Is there some other magic required to make bluetooth goodness happen?

Thank you for sharing your diagnostic wisdom!

Parents Reply Children
  • Thanks for having a look!

    No, I am using "west build" (with various parameters for the combinations given above), and "west flash".

    The "nRF5 Getting Started" documentation doesn't seem to endorse SES for the nRF53, favoring the "nRF Connect SDK" instead:

    infocenter.nordicsemi.com/index.jsp

  • However, the link you provided seems relevant; I'm investigating that now.

  • What version of NCS do you use?

    If you use the latest NCS and don't modify the config, it supposes to build and flash the hci_rpmsg as the child image when using west build for the sample/application. See building-and-programming-a-sample.

    Do you see it build hci_rpmsg in the log while building with "west build"? 

    -Amanda H.

  • Hi Amanda,

    Thank you for following up!

    I tried installing SES but I encountered the same problems I've seen in the past.

    This private label Nordic version of SES, an extractable tgz, is usable but does not contain a board definition for the nRF5340-DK:

    http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/gs_installing.html#installing-ses

    The newer version on the Segger site is not installable on my Linux system, which is as it has been for time immemorial. The installer complains about some problem with the X display and I've never figured out how to get around that, despite following the advised remediations.

    I haven't been able to make sense of the documentation for building multi-platform images with west. The CLI usage examples I've seen require a platform target--one of the secure app processor, the insecure app processor, or the network processor--and I don't know how to twiddle the right knobs to build a proper network processor image or multi-platform image. I tried targeting nrf5340dk_nrf5340_cpuapp, then nrf5340dk_nrf5340_cpunet (a much larger image, encouragingly), and flashing each, and later flashed periodic_adv to the app processor, but I still don't see any BT activity.

    I also looked at the SoftDevice github repo:

    https://github.com/nrfconnect/sdk-nrfxlib/tree/master/softdevice_controller

    The documentation seems more relevant to the nRF51/52 platforms, where the softdevice is linked into a single image along with application code.

    It's getting late so I will put this project down for the night and try again tomorrow. The learning curve for deploying a stock sample app seems a little steeper than I expected (on the 5340; no problem on the 52832), at least using the west CLI. Sadly I seem to be unable to use SES, plus west debug is also broken because of some hard-coded Python 3.8 dependency conflict in the distributed binary :-/

    If you have any dumbed-down suggestions for getting a working build running on the 5340 using only west or nrfjprog commands, starting with a fully-erased configuration, and exhibiting discoverable BT advertising, I'll be most grateful! 

    Cheers,

    David

  • Wrapping this up, I am unable to get any Bluetooth sample app working properly (e.g. detectably advertising) on my nRF5340-DK. I discern that there are toolchain and documentation obstacles:

    * The private label Nordic SES package is many versions behind what's available from Segger, and does not contain board support for the nRF53 family.

    * The latest release of SES from Segger's site is not installable on Debian Linux with XFCE because of X compatibility problems (a longstanding problem)

    * ARM gdb / west debug is not usable with Debian Linux (absent dangerous and tedious workarounds) because of the unexpected dynamic linking dependency on Python 3.8; this has been discussed in bug reports but doesn't seem to be a priority for the developers

    * Available build tools and processes warn that 5340 support is preliminary, not for production use

    * Clear documentation (especially a walkthrough) of the west/zephyr build+deployment process for the asymmetric dual core 5340 seems to be a pending opportunity

    The nRF52832 is adequate for my current needs, and the development toolchain is working fine for that platform. I am going to pause my investigation of the 5340 for a while, with cautious optimism that the relevant tooling and knowledge base will progress over time. It's also possible that I just have a defective board, in which case time is unlikely to cure the problem. :-) Amanda, if you will please pass along the word, I'll be grateful--nay, thrilled!--if Nordic will put together a detailed walkthrough of the CLI-based deployment process, using west/zephyr and ARM-gcc, that starts with a fully-erased nRF5340-DK and ends with a flashed device that's happily broadcasting advertising packets (and bonus points if it has multi-platform Win+Mac+Linux guidance, like on some of the other Nordic tutorial pages.)

    I get the sense that Windows toolchain support is more mature and robust than Linux. If I need to proceed with the 5340 in the nearer future, I'll reluctantly consider provisioning a Windows development environment. I prefer to keep Windows machines off of my network for security reasons.

    Kind regards and thank you for your attention. I appreciate the excellent expertise and assistance that Nordic staff contribute on this forum.

Related