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 reply.  I manage to trace my problem on the central side, up to ble_nus_c_evt_hanlder(...) function. So before calling err_code = ble_nus_c_handles_assign(...), I placed 

NRF_LOG_INFO("NUS Discovery complete hndl %d", p_ble_nus_evt->handles.nus_tx_cccd_handle );

and I am getting exact the same result as before ie in "good" case scenario I am getting 16 (or 0x10) and in "bad" case scenario I am getting 15 (or 0x0F).

Any suggestions where to look further, please advise?

Second question:

You did mentioned "you should also update to S132v5.1 if you haven't already, this is done by programming the S132v5.1 softdevice, replace the softdevice header files in your project, and re-compile the application."

Therefore I have few questions:

1. Where I can download SD132V5.1? I did look through SDK 14.2 \\components\softdevice\s132\hex and there is only onefile there:  "s132_nrf52_5.0.0_softdevice.hex"

2. Which header file do I need to replace?

3. Do I need to do any changes in the project? ie "Select Target" in Keil there are two projects there:

nrf528832_xxaa

flash_s132_nrf_52_5_0_0_softdevice Do I need to do any modifications here?

 Or, might be there is migration instructions available? 

Regards,

Andrew.

[Andrew_Engineer]

Hi Kenneth,

Did you have a chance to look at this topic, please advise, this issue is very important to us.

Thank you,

Andrew

[Kenneth]

First question:

I am not sure what might be the problem here, I think I will need an on-air sniffer log of "OK" and "bad" to see exactly if the problem occurs on the peripheral or central side. If you are not able to provide that, then the next step may be to look at the BLE discovery module and whether it resets as expected between connections, maybe you can log the service discovery module and see if there is an +1 offset from the start or not.

Second question:

The S132v5.1 can be downloaded from here: http://www.nordicsemi.com/eng/nordic/Products/nRF52832/S132-SD-v5/58987 

Program the S132v5.1 softdevice binary, replace the header files in \components\softdevice\s132\headers, and re-compile project.

[Andrew_Engineer]

Hi Kenneth,

 

Thank you for your replay.

 

Very good point with regards to on-air sniffer, we are actually planning to get one, can you please recommend decent sniffer, or if there is any binaries (hex file) what we can program in to the development board (we are using NRF52 PC10040) and use it as sniffer. Any suggestions recommendations are very well welcome.

 

I also want to look deeper in the BLE discovery module, can you please pointed this module in the code, where should I look, please also indicate how I can reset this module through my application ie if there are any specific APIs calls?

 

Thank you for pointing out new SD132 V5.1 location, I just have quick question what is desired settings should be used for IRAM1 and IROM1, for the system without bootloader and system with buttonless bootloader I was trying to find “migration guide” but I was out of luck.

 

 

Thank you, for all your help and support

 

Andrew

[Kenneth]

Hi,

As a sniffer you can use any nRF52-DK:
https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF-Sniffer/(language)/eng-GB

You may reset the discovery module by actively calling ble_db_discovery_close() and ble_db_discovery_init() between connections, but that should not be necessary. Because in ble_db_discovery_on_ble_evt() there is already handling of BLE_GAP_EVT_DISCONNECTED, which calls on_disconnected() and should in essence do the same. Though maybe there is some race condition here in your code. So you may for debugging try to print out when BLE_GAP_EVT_DISCONNECTED and BLE_GAP_EVT_CONNECTED occurs relative to calling ble_db_discovery_start().

Also, I noticed discovery_start() will always return NRF_SUCCESS, even if sd_ble_gattc_primary_services_discover() may return an error code. It would be interesting if you could print out the actual return code from sd_ble_gattc_primary_services_discover() in discovery_start(), and see if there is an error shortly before your problem occurs.

There is no change in project settings moving from S132v5.0->S132v5.1.

Best regards,
Kenneth