samples: bluetooth: peripheral_hids: Unable to communicate with paired device after board reset

[ghost]

Describe the bug
After building the peripheral_hids sample source, I paired the Desktop with the board.
I confirmed that the value of the battery is reduced well by modifying the source to reduce by 1 per 500ms.
Reset the board succeeds in reconnecting, but does not reduce the value of the battery.

Environment (please complete the following information)
OS: Linux ubuntu 18.04
Toolchain: zephyr-sdk-0.11.1
Commit SHA or Version used: 7a3b253

To Reproduce
Steps to reproduce the behavior:

1. mkdir build; cd build
2. cmake -DBOARD=nrf52840dk_nrf52840 ..
3. west flash

Expected behavior
Reset the board (power off and on) should also reduce the value of the battery on the paired device (Desktop).

Additional context

(Modified test source)

void main(void)
{
	uint8_t battery_val = 100;

	err = bt_enable(bt_ready);
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
		return;
	}

	bt_conn_cb_register(&conn_callbacks);
	bt_conn_auth_cb_register(&auth_cb_display);

	while (1) {
		if (battery_val == 10) {
			battery_val = 100;
		}
		bt_bas_set_battery_level(battery_val);
		battery_val--;
		k_msleep(500);
	}
}

Logs and console output

(First-time connection)

(Verify connections and battery values are reduced)

(board reset)

(debug message after reset)

The connection with the paired device is successful by resetting the board, but the value of the battery is not decreasing.
Is there a way to enable battery service separately?
It is connected to a paired device, but why doesn't the value of the battery decrease?
I'd appreciate it if you could reply.

[joerchan]

The CCC is not stored in flash when the board is reset. CCCs are by default stored in flash when the connection is disconnected.
If the use-case is to support this reset in the middle of the connection then CONFIG_BT_SETTINGS_CCC_STORE_ON_WRITE should be enabled.

[ghost]

The CCC is not stored in flash when the board is reset. CCCs are by default stored in flash when the connection is disconnected.
If the use-case is to support this reset in the middle of the connection then CONFIG_BT_SETTINGS_CCC_STORE_ON_WRITE should be enabled.

As you said, we tested it by setting it to CONFIG_BT_SETTINGS_CCC_STORE_ON_WRITE=y.
Once the board has been reset, the connection with the paired device is successful.
However, the problem is not solved.
There is still no change in the value of the battery.
We tested it on the nrf52840dk_nrf52840 board and the nucleo_wb55rg board.

[joerchan]

@wngur300 Did you remove the existing bond before trying? west flash --erase would make sure that existing bonds from previous testing is removed, since that one is stored without the CCC previously.

From the commit that you have put in the issue description you have Zephyr v2.4.0 release, can you try to switch to v2.4-branch?
There is a fix to Lazy loading of CCCs after 2.4.0 release, and Lazy loading seems to be on in this sample.

[ghost]

@wngur300 Did you remove the existing bond before trying? west flash --erase would make sure that existing bonds from previous testing is removed, since that one is stored without the CCC previously.

From the commit that you have put in the issue description you have Zephyr v2.4.0 release, can you try to switch to v2.4-branch?
There is a fix to Lazy loading of CCCs after 2.4.0 release, and Lazy loading seems to be on in this sample.

When c2a0b0f commitment is applied and CONFIG_BT_SETTINGS_CCC_STORE_ON_WRITE=y is set,
it works well even after the board is reset.
The problem has been solved. Thank you!

[ghost]

@wngur300 Did you remove the existing bond before trying? west flash --erase would make sure that existing bonds from previous testing is removed, since that one is stored without the CCC previously.

From the commit that you have put in the issue description you have Zephyr v2.4.0 release, can you try to switch to v2.4-branch?
There is a fix to Lazy loading of CCCs after 2.4.0 release, and Lazy loading seems to be on in this sample.

I'd like to ask you a question that has nothing to do with the issue.
Is there a function that can confirm that the board is paired with another device after it is powered on?

[joerchan]

@wngur300 There is bt_foreach_bond function, that can be used to iterate over all the bonds, you can see how many there are, and the address of the peer that is paired. You can also remove a bond with bt_unpair.

Closing as problem has been solved.