Adapting the Keyboard HID example to the nRF52840 Dongle

[Pandoril]

Hello Nordic Community,

I'm now struggeling for quiet some time with trying to get the Keyboard HID example to work with the nRF52840 Dongle.

I already read the complete tutorial on this topic https://devzone.nordicsemi.com/guides/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial, but it didn't get me any further.

The problem I'm facing is the following:

After I programmed the Dongle with the adapted keyboard program, I can see the dongle advertising in the nRF Connect App on my Android phone, but I can't connect / bond with it. I also can't even see it on either my Android phone, Linux PC or Windows PC when trying to connect via Bluetooth. The same also happens with an adapted HID Mouse example.

I literally changed nothing in the example, except the preprocessor definition, which should be BOARD_PCA10059.

Just for some more information, heres the software and SDK version I use:

Development is done on Windows

SES 6.30 (to program)

nRF Connect for Desktop 3.11.1

nRF Programmer 3.0.3 (to programm the Dongle)

Softdevice s140_nrf52_7.2.0_softdevice

nRF SDK 17.1.0 (I also tried 15.0 and 16.0, with the same effect)

To be fair, I really don't know what I'm doing wrong, since the example should work out of the box from everything I've found and read online.

---

Also, just to add to this. What I also found during testing was that the LEDs on the dongle didn't work properly with the HID Keyboard example.

I needed to change NRF_LOG_BACKEND_UART_ENABLED to 0 in the sdk_config.h to make them have the correct functionality.

But that still didn't change anything with regards to the main problem.

[Vidar Berg]

Hello,

Please try the .hex attached below and see if it works for you. I used the ble_app_hid_keyboard sample from SDK 17.1.0, changed the board name, and disabled logging.

ble_app_hids_keyboard_pca10056_s140_with_s140.hex

2768.ble_app_hids_keyboard.zip

Best regards,

Vidar

[Pandoril]

Hello,

sorry for the late answer, I was gone a few days.

I tried the attached Hex as well as compiling a Hex from the attached code and both files produced the same problem.

But something interesting I found out: If I set the following line

init.config.ble_adv_whitelist_enabled          = false;

in the advertising_init() function, the dongle / program functions as expected (except obviously the whitelist functionality).

This is good, since I can program for now, but I would really like to use the whitelist functionality in the future. But I'm at a bit at a loss with this problem right now.

[Vidar Berg]

Hello,

Ah, that explains it. So the dongle must have had existing bonding information on it since it started advertising with a whitelist instead of openly.

On the DK, we have button 2 which you can use to delete all bonds or restart advertising without the whitelist filtering, but the dongle only has one, so you will have to assign this functionality to button 1 instead.

[Pandoril]

Ah ok interesting, I will try that and then report of my changes to the code and other findings later.

But just for my own understanding and clarification for now - does that mean the dongle stores the bonding information, even if another sofdevice + Hex is flashed onto it? Probably in some non-volatile memory in the SoC?

[tesc]

Hi,

Yes, the bonding data is stored separately from stack and application in flash, in the area for "application data". Upgrading the application will not overwrite or erase the application data.

This is especially true for a Dongle, where the appliation is not programmed directly to the SoC through use of a debug probe / J-Link, and so an "erase all" operation on the flash is not available. (Which would be the preferred way to ensure a "fresh" start on an SoC when you have direct programmer access, i.e. not relying on DFU for upgrading the app.)

Regards,
Terje