nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

connecting nrf52840dk to nrf52840dongle uart examples

user116179 over 4 years ago

Greetings All,

I am trying to connect an nrf52840dk board to an nrf52840dongle for wireless serial communication.

I flashed the nrf52840dk with the central_uart sample and the nrf52840dongle with the peripheral_uart sample.

I'm using version 1.9.1 of the nRF Connect SDK

I can't seem to get them to pair automatically, so, no serial activity possible.

(red led on nrf52840dongle does light, indicating a connection)

Here is the debug terminal output.

[00:00:08.444,152] <inf> fs_nvs: 8 Sectors of 4096 bytes
[00:00:08.444,183] <inf> fs_nvs: alloc wra: 0, fd0
[00:00:08.444,183] <inf> fs_nvs: data wra: 0, 1c
[00:00:08.444,305] <inf> sdc_hci_driver: SoftDevice Controller build revision:
0e e7 c5 66 67 18 3c ac b3 d2 cc 81 a3 dc f1 c0 |...fg.<. ........
c0 36 02 22 |.6."
[00:00:08.448,944] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:08.448,944] <inf> central_uart: Bluetooth initialized
[00:00:08.452,728] <inf> central_uart: Scan module initialized
[00:00:08.452,728] <inf> central_uart: NUS Client module initialized
[00:00:08.460,998] <inf> central_uart: Scanning successfully started
[00:00:19.828,613] <inf> central_uart: Filters matched. Address: FE:DB:32:64:13:31 (random) connectable: 0
[00:00:19.928,100] <inf> central_uart: Connected: FE:DB:32:64:13:31 (random)
[00:00:20.029,388] <inf> central_uart: MTU exchange done
[00:00:20.179,321] <err> bt_smp: reason 0x8
[00:00:20.179,809] <wrn> central_uart: Security failed: FE:DB:32:64:13:31 (random) level 1 err 9
[00:00:20.180,236] <wrn> central_uart: Pairing failed conn: FE:DB:32:64:13:31 (random), reason 9
[00:00:20.879,241] <inf> central_uart: Service discovery completed

Any thoughts?

Thank you.

Parents

0 user7377 over 4 years ago

Hi,

It looks like the devices bonded before, but you deleted the bonding information (perhaps did a full flash erase?) one one of the devices? If so, the fix is to delete the bond on the other device as well so that they can pair.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 user116179 over 4 years ago in reply to user7377

Greetings Einar,

Thank you for your reply.

Pardon my ignorance, but how does one go about deleting a bond?

Thank you
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 user7377 over 4 years ago in reply to user116179

Hi,

To do it programatically you need to call bt_unpair(). But if the issue here is just something that happened when testing, for instance because you flashed both peers with the respective firmware and then reased and re-flashed one of them, a simple fix would be to erase and reprogram both devices. If you do, erasing will also remove any bonding data and they can pair again.

Edit: If this is indeed the issue, you can also change the configuration to allow repairing by adding CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE=y to your prj.conf.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 user116179 over 4 years ago in reply to user7377

Greetings Einar,

I'm not sure if this is a bonding issue.

I added CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE=y as the last line under the "ENABLE BONDING" group in the prj.conf file in both central_uart and peripheral_uart samples, Reloaded thru Segger for Nordic V5.60 with clean build directory box checked, recompiled and re-flashed both binaries to their respective boards. I still get the exact same output in the debug terminal.

Any alternative theories?

Thank you
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 user116179 over 4 years ago in reply to user7377

Greetings Einar,

I'm not sure if this is a bonding issue.

I added CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE=y as the last line under the "ENABLE BONDING" group in the prj.conf file in both central_uart and peripheral_uart samples, Reloaded thru Segger for Nordic V5.60 with clean build directory box checked, recompiled and re-flashed both binaries to their respective boards. I still get the exact same output in the debug terminal.

Any alternative theories?

Thank you
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

0 user7377 over 4 years ago in reply to user116179

Hi,

I see, there is another issue then. If I test with unmodified examples from 1.9.1 with a DK as central and dongle as peripheral, I get this log, as expected:

00> [00:00:00.011,566] <inf> fs_nvs: 8 Sectors of 4096 bytes
00> [00:00:00.011,596] <inf> fs_nvs: alloc wra: 0, fe8
00> [00:00:00.011,596] <inf> fs_nvs: data wra: 0, 0
00> [00:00:00.011,749] <inf> sdc_hci_driver: SoftDevice Controller build revision: 
00>                                          0e e7 c5 66 67 18 3c ac  b3 d2 cc 81 a3 dc f1 c0 |...fg.<. ........
00>                                          c0 36 02 22                                      |.6."             
00> [00:00:00.016,784] <inf> bt_hci_core: No ID address. App must call settings_load()
00> [00:00:00.016,784] <inf> central_uart: Bluetooth initialized
00> [00:00:00.018,890] <inf> central_uart: Scan module initialized
00> [00:00:00.018,920] <inf> central_uart: NUS Client module initialized
00> [00:00:00.029,571] <inf> central_uart: Scanning successfully started
00> [00:00:15.718,414] <inf> central_uart: Filters matched. Address: C6:A3:38:69:C3:45 (random) connectable: 0
00> [00:00:16.038,696] <inf> central_uart: Connected: C6:A3:38:69:C3:45 (random)
00> [00:00:16.139,862] <inf> central_uart: MTU exchange done
00> [00:00:17.647,277] <inf> central_uart: Pairing completed: C6:A3:38:69:C3:45 (random), bonded: 1
00> [00:00:17.647,552] <inf> central_uart: Security changed: C6:A3:38:69:C3:45 (random) level 2
00> [00:00:18.339,721] <inf> central_uart: Service discovery completed

You get error 9, which is BT_SECURITY_ERR_UNSPECIFIED. I do not immediately have any other theories. Do you by any chance have two DKs, so that you can easily get logs from the peripheral side and debug that as well? Or try with the peripheral on the DK and central on the dongle and share the log from the peripheral?