nrf5340 reports BLE is active when running samples and viewed via RTT, but the device is not visible from any BLE scanner

Heyyy guys!

It is possible that I'm doing something wrong, but i'm confused as this was definitely not an issue at some point while i've been working with the 5340.

I'm an app developer so I don't often dive too deeply into this kind of thing, and other people around me are equally unsure.

However everything seems correct in this case, and it's easily reproducible, so maybe it's something straightforward?

---

Basically - when I flash some sample to my 5340dk (using VSCode, or West), everything goes well, the board restarts, the LEDs flicker, and I see this in RTT:

00> [00:00:00.485,168] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
00> [00:00:00.485,198] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
00> [00:00:00.485,229] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 51.10872 Build 1643454488
00> [00:00:00.489,379] <inf> bt_hci_core: Identity: F3:42:9B:11:89:0B (random)
00> [00:00:00.489,410] <inf> bt_hci_core: HCI: version 5.3 (0x0c) revision 0x2136, manufacturer 0x0059
00> [00:00:00.489,410] <inf> bt_hci_core: LMP: version 5.3 (0x0c) subver 0x2136

But the device is not visible when I check for devices around me.

If there are some things I am missing here, or perhaps some links you can point me to to figure this out, that would be great!

As for my env - I'm on a Mac OS 12.5, using west v0.13.1, and i've so far tried the following on the nrf toolchains 1.9.1, 2.0.0 and 2.0.2

Steps to recreate:

  • 'open terminal' from nrf connect toolchain
  • cd <toolchain>/zephyr/samples/bluetooth/peripheral_hr
  • west build -b nrf5340dk_nrf5340_cpuapp
  • west flash --recover

---

Some additional notes:

I can remember at one stage that I was able to flash (from VS Code, using the nrf plugin) some application core sample like peripheral_hr that I edited, and then afterwards flash an hci_rpmsg image to netcore, and it worked correctly on my 5340 then, although I've updated one thing or another now and that doesn't work anymore. The same issue was happening before I "re-flashed" hci_rpmsg, whereby I could see in an RTT Viewer that advertising was started, but I was unable to actually detect the device, until re-flashing - but I'm not remotely sure if that's related.

We do have another board that I connect to via my 5340dk to run samples on, and this works correctly for most (but not all) samples, making me think there is some particular issue with my own board, however I tried another team members' 5340dk today, and same issue was happening as with me. That could suggest it is my environment, but it's hard to be sure.

When my Nrf Connect for Desktop Programmer App (3.0.3) is able to connect to my device (it frequently fails due to readback protection issue, and I have to try to reconnect until it reads successfully) I am actually able to flash hex files for the hci_open_amp.hex and peripheral_hr.hex and this works, but I want to be able to deploy myself

Any other info I can provide to help, I shall do!

Thanks for your time guys! :)

Parents
  • Hi

    I just tested this sample with NCS v2.0.0 with both the West commands you provided and the VS Code extension had no trouble building, flashing or detecting the board as "ZEPHYR HEARTRATE SENSOR" in my phone's nRF Connect application after the fact, so I think it might be an issue with your NCS installation. The west build and west flash are both done correctly without error messages, right? I would recommend trying to reinstalling your NCS altogether either with the Toolchain manager or manually by following this guide. If the path to the NCS installation is already long it might be a good idea to get it closer to the root of the path as that has caused issues in the past.

    But since this occurs on a specific board (if I understand you correctly) can you provide some details on the DK you're using. What revision of the nRF5340 DK is this? Is per chance solder bridge SB40 cut on it for doing current measurements at some point? That could cause an issue like this. If so you need to short the pins on Pin header P22.

    Best regards,

    Simon

  • Just as an update, I spoke about it with my colleague and he is going to try another board he has which has some different bridges cut. I can confirm however on my own DK that the SB40 bridge is not cut - is there perhaps some other things I can investigate related to bridges being cut or not? As far as I understand however, this one came out of the box before it came to me, but I'll look at this a little bit more later today.

    Some board info from the programmer logs, if this is relevant:

    Device family NRF53
    Device version NRF5340_xxAA_ENGB
    Board version PCA10095

      

Reply
  • Just as an update, I spoke about it with my colleague and he is going to try another board he has which has some different bridges cut. I can confirm however on my own DK that the SB40 bridge is not cut - is there perhaps some other things I can investigate related to bridges being cut or not? As far as I understand however, this one came out of the box before it came to me, but I'll look at this a little bit more later today.

    Some board info from the programmer logs, if this is relevant:

    Device family NRF53
    Device version NRF5340_xxAA_ENGB
    Board version PCA10095

      

Children
No Data
Related