Problem communication between BLE_APP_UART_C and BLE_APP_UART (TX notifications are not always enabled)

[Andrew_Engineer]

Hello Nordic Guys,

 

 

 

We are working on the system based on BLE_APP_UART_C (central) and BLE_APP_UART (peripheral).

“Central” is always “ON” and scanning for the peripherals.

“Peripheral” wakes up every 5 minutes, connects to the “Central”, sends data, and going back to sleep.

 

System works perfectly when “peripheral” were based on SDK 11 S132 Version 2, now we are migrating to SDK14.0 S132 V5, and experiencing some challenges. (In both cases “Central was always build on SDK14 SD 132 V5)

 

What we are noticing is bellow:

 

1. “Central” is connected to the “peripheral”
2. “Central” is enabling tx notifications by calling function: ble_nus_c_tx_notif_enable(..)

 

On the “peripheral” side we seeing follow behavior:

 

1. “Peripheral” is connected to the “Central”           GAP_EVT_CONNECTED
2. Exchange MTU response event ie “Central” and “Peripheral” is trying to negotiate data package size                                       BLE_GATTC_EVT_EXCHANGE_MTU_RSP
3. BLE_GATTS_EVT_WRITE with event ID 80 and length 20, we are assuming this is a point where “Central” is enabling Notifications on “Peripheral”.

 

What we are experiencing: it seems like Notifications is not always enabling on the “Peripheral” side ie if we try to send message from the “Central” to the ”Peripheral” it is going to be delivered.

 

In “good” case scenario after receiving BLE_GATTS_EVT_WRITE we are getting BLE_NUS_EVT_COMM_STARTED, but in “bad” case scenario we are not getting anything and after roughly 10-12 seconds we are getting: BLE_GAP_EVT_CONN_PARAM_UPDATE. But we still not able to communicate between “peripheral” and central. Once “peripheral” is disconnected from the “Central” on the next connection attempt system could communicate, but behavior is random.

 

Question: if there is way on the “Peripheral” side to make sure Tx notifications had been enabled?

 

What would be the word of advice how we can address this issue?

 

 

Thank you,

 

 

Andrew.

[Andrew_Engineer]

Hi Kenneth,

 

Thank you very much for your replay. I did try follow:

 

1. Print error code after calling sd_ble_gattc_primary_services_discover(..) always returns NRF_SUCCESS
2. I also try to re-initialize discovery module by calling db_discovery_close() in BLE_GAP_EVT_DISCONNECTED. Then I called ble_db_discovery_init(…) and nus_c_init(…) before calling start_scan(…)

 Nothing helps…

 I tried to print from function ble_db_discovery_on_ble_evt, case BLE_GATTC_EVT_CHAR_DISC_RESP :

p_ble_evt->evt.gattc_evt.conn_handle and it is always returns 0

 Question if there is chance I can print cccd_handler from ble_db_discovery_on_ble_evt function, if I can please advise…

 

I am going to look at the sniffer tomorrow and adivse

 

 

Regards,

 

Andrew

[Kenneth]

Let me know when you have the sniffer log. Thanks.

[Andrew_Engineer]

bad communication.pcapnggood communcation.pcapng

Hi Kenneth,

 

Attached wireshark logs: for “good” and “bad” communication. I tried to decipher myself, but quickly realized I need expert help, can you please have look and advise.

 

Also, one more question: What is nature of the tx_cccd_handle: ie is it random generated number? Is this number client supposed to communicate to central? Or Central somehow generate this number? Can you please elaborate a bit on this..

 

 

Thank you for all your help.

 

Regards,

 

 

Andrew

[Kenneth]

Hi,

There is something odd happening here:

- It seems that in bad log the peripheral trigger an MTU exchange on connection event, this does not occur in good log. This does not explain your issue, however it is inconsistent behaviour.
- In bad log the peripheral reponse with handles from 0x000b->0x0010, while in good log the peripheral response is 0x000c->0x0011. This does not explain your issue either, however it is inconsistent behaviour. In both cases it's the peripheral that has inconsistent behavior.

It may seem as a bug of some sort, possible because "something" is not initialized/memset() properly. I suggest to use SDKv14.2 and S132v5.1 if you haven't already. Also try to look into why you are sometimes triggering MTU exchange. Not sure what compiler you are using, but possible change optimization is a long shot. 

The handles will be generated sequentially, but for the same firmware they should be the same each time.

Best regards,
Kenneth

[Andrew_Engineer]

Hi Kenneth,

Sorry for the delay with replay. I did upgrade central to SD5.1 SDK14.2 and problem seems to disappear .

Regards,

Andrew