nRF Connect can not read Characteristics after connect

[bama]

Hello,

we have made our fist device with a custom Service with 5 characteristics. And now we have a strange problem which I was not able to debug to find a solution.

We start Advertising on Tag and this will then be reognized on the NRF Connect PC Application. 

NRF Connect will connect to the Tag and the program has checked our Service. We then click on the Service to read out the Service and the Characteristics.

Normally I see then the 5 Characteristics and I have also seen the correct data read from Device.

On the Device which is connected I see then also the Debug Informations for the events e.g. BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST ...

But in some cases the nRF Connect is not able to read out the Service and Characteristics if I click on the Service within nRF Connect. Then the read animation on the Pc Program will turn and turn but the Service and characteristics will not be read.

On the Device I can see the dbug informations for the connection but I will not get events like BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST. And I can also not see that the data was read.

We have the same problem also if we use not nRF Connect but a different Bluethooth central to connect. Also there we are somethimes not able to read the service and characteristics. There we have then the information that we was able to read out the characteristics from the Service (so we see our 5 characteristics) but then we are still not able to read out the data.

We are then still connected. So we can disconnect and will then see these events on the Tag. On the next adv we can again connect but also there we then the same problem again.

We have that problmes on different on our Devices but it is very often but anyway randomly!

We use SDK nRF5SDK160098a08e2

regards

markus

[Hung Bui]

Hi Markus, 

Could you capture a sniffer trace when the issue happens ? The sniffer can be downloaded here: https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Sniffer

Usually for service discovery, there shouldn't be an event for BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST. A sniffer trace would reveal what behinds the event. 

Have you checked the log on the device ? Do you see any assert ? 

[bama]

Hello Hung Bui,

I was struggling with the installation of this Wireshark solutions!

But now i was able to do the sniffer trace. In addition I have two traces. One with a working connection and one with the error.

not_working.pcapngworking.pcapng

on the Log on the Target I can only see that the central will not read the data from my characteristics. But I get not assert or error.

[bama]

Hello Hung Bui,

yes we have jused clicked on connect on nrf connect and then clicked on our Service to read it.

And yes thsi characteristic is one where we have enabled the auth req.

We have Tag's where we don't have this problem over day's and Tags where we have it nearly after on each connect.

OK if the auth req is the problem. How will teh application know that there was such an auth req if the SD will not give us the Event?

The reason why we use the auth req. is that we have data to read which should be uptodate just when we want to read it. But we don't get any information from the SD if someone want to read it or if someone has read it. So we wait until we get the auth req. and before we send back the auth response we set the correcponding data within the SD.

But maybe there is another and better solution to handle such readings.

regards

markus

[bama]

Hello Hung Bui,

another infroamtion about our problem.

We have a Tag wich has the problem nearly every time when we connect. But if we let the tag restart and connect in a short time to the Tag we don't have the problem. There it looks like that everything is ok.

After such a restart we advertise for about 30 seconds and then we stop Adv. The next adv will then be after an event happen on our application. After that we adv. only for one second (200ms interval).

But if we don't connect on the first adv. after startup (30seconds) and want to connect on one of the next adv. (which are only 1 second) then we have the problem nearly each time.

At the moment we test with about 4-5 Tags and only 1-2 has the problem sometimes. The order 2-3 has the problem nearly every time.

regards

markus

[Hung Bui]

Hi Markus, 

It would be very strange if the softdevice doesn't send the event to the application. But there is a chance that the application didn't poll the event from the softdevice. It's trigger by an interrupt (SD_EVT_IRQ) and the application has to call sd_ble_evt_get() to get the event. It is usually handled by the nrf_sdh module. But if you have something that run in interrupt context (APP HIGH for example) that takes a long time it may block the nrf_sdh module from polling the softdevice event. 

It's quite strange that only on some devices you have the problem, I assume that they have the same firmware ? I don't see a reason why connecting on the slow advertising would cause this problem.

If you try to turn off any feature that is performed in a interrupt context (including BLE events) and can take a long processing time (or deadlock) until the problem disappear, we may be able to pin out what cause the problem. 

[bama]

Hello Hung Bui,

we only use one gpio interrupt and the app_timers. And when the problem occure we have disabled this interrupt. So at the moment I don't know what I should disable.

[Hung Bui]

Could you reproduce the issue on a nRF52 DK? If you can, please provide a minimized firmware that we can test and debug here.