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

[acaskey]

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! :)

[Simonr]

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

[acaskey]

Hey Simon, happy Monday!

Thanks for your response.

To clarify, we have a bunch of 5340s that devs and internal people use for testing, but there is a 5340 on a SOC that is also in pre-production testing. When I try on our DKs, I note the issues i am seeing, or at least, I haven't found a 5340dk in our team yet that 'just works', however I am able to successfully deploy the samples without issue to some hardware - i.e., the SOC. So i feel like it must not be something major in my environment. But would you prefer some build logs with 2.0.0 or 2.0.2 to see? Are you also building the samples on MacOS?

Oh, to add to this, I have reinstalled the toolchain and the NRF connect for desktop and all its files multiple times and same result. I will do it again at some point today and try to remove everything and set it up again, perhaps something didn't get cleared before.

With 'shorting the pins' can you guide me how to do this? I don't see any damage to the board or anything obvious. I applied a little header thing over the P22 pin header but I don't think it did anything. I'm an app developer.. :P I'm not sure what this does - why might this work? The boards were used by other more electronically technical people before they were given to people like me, so it's possibly that they did some things to the board that I might not be able to recognise without some pointers.

However, I can use the NRF Connect for Desktop programmer tool to program hex files from your samples page (the Heart Rate + openamp samples used as like a first flash step when setting up the board), and this works. Also, at one stage I made some combination of bootloader + sample that actually did work on the board, I even demo'd this multiple times, however I've updated my toolchain, or west or something and now this doesn't work anymore. But I think hardware definitely works, there's just some weirdness in configuration or something else.

Is there some way to find out if there was any issues that may not be detected when starting up? I didn't include it in my original RTT output, but if I turn on debug logging you do see "Advertising started successfully" etc.

[acaskey]

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