Closed Qbicz closed 5 years ago
@JoeHut is it similar to what you have seen?
@nvlsianpu @Vudentz @jhedberg
You need to set LOG_BT_SETTINGS_CCC_STORE_ON_WRITE=1
. But yes that is the same issue as we have.
Be aware of this issue I am working on: https://github.com/zephyrproject-rtos/zephyr/issues/11409#issuecomment-440630063
@Olivier-ProGlove Thanks for the link. BT_SETTINGS_CCC_STORE_ON_WRITE
fixes the problem in most cases, but not when you perform the discovery but don't subscribe to any notification. There is no CCC write then and this bug reveals.
You are right. It is also true we saw this issue even after enabling LOG_BT_SETTINGS_CCC_STORE_ON_WRITE=1
but much less frequently.
Describe the bug When central connects, but does not subscribe to any notification, an invalid base64 value is written to settings - after wake up the settings subsystem tries to decode the GATT CCC and crashes.
Problem occurs in
subsys/bluetooth/host/gatt.c
inbt_gatt_store_ccc()
function when it usessettings_str_from_bytes()
fromsubsys/settings/src/settings.c
. https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/host/gatt.c#L2522In the log output it's visible that settings subsystems stores BT ID, then BT keys and then tries to store BT CCC which has not been modified as some invalid base64 value.
To Reproduce Steps to reproduce the behavior:
samples/bluetooth/peripheral_hids
samplenrf52_pca10040
ornrf52840_pca10056
nrfjprog -e
and flash the sampleExpected behavior Value written to flash should be possible to decode or nothing should be written.
Screenshots or console output
Build environment (please complete the following information):