A Problem on Buttonless DFU + Bonding valid.

[cw-park]

Currently, we are testing that 「buttonless DFU + Bonding valid」 in our App.

But After performing F / W Update with DFU, other BLE Service became invisible.(※2)

So, as a result of comparing the log of the Normal Project(No problem) with the log of the current problem project,

I found that there are the following differences.(In the normal case, the following events will occur.)

· PM_EVT_SERVICE_CHANGED_IND_CONFIRMED
· PM_EVT_PEER_DATA_UPDATE_SUCCEEDED

And Compared & checked "sdk_config.h", "makefile", "linkscript file", "source file", etc. But did not find a place likely to be a cause.

How can I solve this problem?

Why does the above log difference occur?

Please answer me about my question.

※ SDK Version

     nRF5_SDK_15.0.0_a53641a

※ IC

     nRF52832

※ Problem Project'SDK Config File

sdk_config.h

(※2)

<Before DFU Update>

     

<After DFU Update>

[Hung Bui]

Hi Cerevo, 

 

I suspect that the service changed characteristic was not included in either the application or the bootloader.

I would suggest to turn off and on the iPhone and test again. 

 

You mentioned  a "normal case" what was that ? Which firmware did you use when you have a normal case ? 

 

Have you test and verify your new firmware actually has other services ? (test without bootloader, flash softdevice + application directly)

[cw-park]

Hi Hung Bui,

>I suspect that the service changed characteristic was not included in either the application or the bootloader.

No, both Bootloader (DFU) and Application are defined and activated as follows.

#define NRF_SDH_BLE_SERVICE_CHANGED 1

> I would suggest to turn off and on the iPhone and test again.

I tested it again, but it was the same result.

> You mention a "normal case" what was that? Which firmware did you use when you have a normal case?

I added Device Information Service based on "ble_app_buttonless_dfu" in example and tested it.

This is OK, DIS (Device Information Service) is displayed even after F / W Update.

> Have you test and verify your new firmware actually has other services ? (test without bootloader, flash softdevice + application directly)

Yes, My Application includes "DIS", "Battery Service", and self-defined Service like the attached photo ("Before DFU Update").

Of course, it is tested and there is no problem.

So, you do not know why this problem happens after all?

[Hung Bui]

Hi Chan,

 

I think we found the root cause of the issue. When you set the MTU to something else not the default that the iPhone set when connected, the nrf_ble_gatt.c will try to request sd_ble_gattc_exchange_mtu_request() immediately right after CONNECTED event. 
This process will take some time, and if we call sd_ble_gatts_service_changed() right after that call we will receive error 9x08 NRF_ERROR_INVALID_STATE. In the description of sd_ble_gatts_service_changed() you can find: 

 

* @retval ::NRF_ERROR_INVALID_STATE One or more of the following is true:
* - Invalid Connection State
* - Notifications and/or indications not enabled in the CCCD
* - An ATT_MTU exchange is ongoing

My suggestion is to modify the code to delay the MTU exchange after we finish with sending service changed indication. 
I will report this to R&D to get it fixed in the future. 

[cw-park]

Hi Hung.

I am sorry that confirmation is delayed.

when 「NRF_SDH_BLE_GATT_MAX_MTU_SIZE」 is defined as 247,

Rather, the Event of「BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST」does not occur.

(Conversely, when 「NRF_SDH_BLE_GATT_MAX_MTU_SIZE」 is defined as 23, the Event of 「BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST」occurs).

so that Because of "An ATT_MTU exchange is ongoing", The NRF_ERROR_INVALID_STATE error will not occur.

It seems to be a different timing problem.

By the way,

I would like to test the following proposal separately.

I would be grateful if you could give me a more specific method.

「My suggestion is to modify the code to delay the MTU exchange. 」

[Hung Bui]

Hi Chan,

BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST is the event when the central (iphone) request MTU exchange. We are not talking about that, we are talking about the opposite, the nRF5 requests MTU exchange. 

You can simply test this by comment out sd_ble_gattc_exchange_mtu_request() call inside on_connected_evt() in nrf_ble_gatt.c to test if it works. 

If it works, then you can think of adding a timing delay before calling that function, so that in case the central didn't do a MTU exchange request, we can request from our side. 

[cw-park]

Hi Hung.

I understood what you said. Thank you.

And I comment out the 「sd_ble_gattc_exchange_mtu_request ()」 from 「on_connected_evt ()」 and tried the test.

For this reason too, the problem seems to have occurred in 「sd_ble_gatts_service_changed ()」.

However, I want to take permanent measures against this problem.

In other words, because of delay is not good in event driven processing based on interrupt, The following measures were taken.

There was no problem with the test.

・#define NRF_BLE_GATT_BLE_OBSERVER_PRIO 1 → #define NRF_BLE_GATT_BLE_OBSERVER_PRIO 2

But I am curious about the effect on this.

Please let me know if there are any problems.

[Hung Bui]

I'm not sure why changing NRF_BLE_GATT_BLE_OBSERVER_PRIO can solve the problem. 

By "timing delay" I'm not talking about a loop delay, but about to start a timer and only trigger sd_ble_gattc_exchange_mtu_request () after a period of time. 

You are saying that by commenting out sd_ble_gattc_exchange_mtu_request () you still have trouble when calling sd_ble_gatts_service_changed() ? Could you check which error code you have ? A sniffer trace would really help as well. 

[cw-park]

You don’t know about NRF_BLE_GATT_BLE_OBSERVER_PRIO .

OK. thanks.