Constantly getting BLE_GAP_EVT_DISCONNECTED although BLE traffic correct

[olgo]

I am working on a BLE to ANT (Specifically FTMP to FE-C) gateway.

HW used is the pca10059 dongle.

Windows10, Programmer 3.0.4, Segger 5.42a.

SW is nRF5_SDK_17.1.0_ddde560

Softdevice ANT_s340_nrf52840_6.1.1.

ANT part works and BLE part sort of works also but I cannot figure out why I am getting BLE_GAP_EVT_DISCONNECTED(GATT_CONN_LMP_TIMEOUT) every about 40s.

Being a newbie on BLE, I decided to start from the ble_hrs_c example and adapt it (also taking inspiration from ble_lbs_c. 

I registered a new UUID for the FTMP (0x1826) successfully.

I manage to connect to the FTMP trainer, which grants me a total of 10 services (had to increase the max # of services to 10 to get them all).

I save the cccd handles of my needed services and use them to request the bike to start transmitting data (does not work for some reason but not the issue of the ticket) and to get notifications from the bike data.

(I can get the nRF Connect app to get the bike to start transmitting data, it seems to remember the state)

All is well, the data appears and is converted to ANT and shows up on mt garmin watch.

BUT! For unknown reasons I keep getting this GATT_CONN_LMP_TIMEOUT every 40s, lose connection to the trainer and need to start over. It reconnects and loses connection 40s later.

If I do not use the cccd handles to request notification nor try to start the trainer via the not working service, I get the exact same behaviour so I guess it probably has nothing to do with them?

I am a bit blind and only have the LED outputs to lead my troubleshooting efforts (and sending debug data over ANT) since I haven't managed to get the log info to the USB port.

Any suggestions what might be causing the timeouts?

Thanks for any advice

/Ola

[Kenneth]

Hi,

An on-air sniffer log would be useful:
https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le 
https://infocenter.nordicsemi.com/topic/ug_sniffer_ble/UG/sniffer_ble/intro.html 

I expect the problem here is that a procedure (e.g. dle or mtu exchange procedure) is initiated on one of the peers, but the other peer does not follow up/respond to the event. In such case the procedure will timeout after for instance 30-40 seconds, and the link will be terminated. If you are able to provide an on-air sniffer log it should be possible to take a look and see if one lack a response, else you will just have to go through the central and peripheral examples and check if there are some ble events that are missing handling in your code by comparing.

Kenneth

[olgo]

Thanks for your suggestion.

After some further reading up on BLE in general and connection handling specifically, I am leaning towards "connection parameter updates" or mtu exchange. Maybe there are other alternatives also, like DLE as suggested.

When I connect using the nRF Connect app (which succeeds without timeouts by the way) together with nRF logger, I can see in debug view that there are a few entries that I possibly do not comply with. I am unsure if they are handled inherently by the SD or if I need to add code for it:

- A number of Connection parameters updated (every 5s or so). Do I need to add code to handle this?

- A number of gatt.SetCharacteristicsNotifications (seems to be one per service). Do I need to add code to handle this? Could it be the cause of the timeout if I don't?

I cannot see any explicit MTU/DLE exchange or similar in the nRF Debug log, but maybe they are not visible?

I will see if I can find any example handlers for such exchanges in the BLE central examples.

Thanks again for your support.

[Kenneth]

In general there are message sequence chart that show procedures, ref:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s340.api.v6.1.1/s340_msc_overview.html
Example DLE:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s340.api.v6.1.1/group___b_l_e___g_a_p___d_a_t_a___l_e_n_g_t_h___u_p_d_a_t_e___p_r_o_c_e_d_u_r_e___m_s_c.html 

Likely you will have a ble_evt_handler() in your code, if you print out p_ble_evt->header.evt_id you can find in ble_gap.h (or other header file such as ble_gattc.h) what they mean, and for instance refer to message sequence charts if any should be followed up. I would likely not print out BLE_GATTC_EVT_HVX since I suspect that will occur a lot (every time a notification is received).

There is no need to do any specific handling on BLE_GAP_EVT_CONN_PARAM_UPDATE event no or set nofications no. Though BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST should be followed up, ref:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s340.api.v6.1.1/group___b_l_e___g_a_p___c_e_n_t_r_a_l___c_p_u___m_s_c.html 

Kenneth

[olgo]

Ok great. In order to understand fully what is going on before attempting to debug further, I borrowed a 52840DK at work and decided to start up the nRF sniffer on it.

Unfortunately, I can not get the sniffer to work. It cannot connect to my board although having flashed the sniffer hex file and seeing LED1 blink (supposedly when it receives BLE packages) so I think it is flashed ok.

However, neither the programmer nor nRF Go is able to program it, but segger seems to succeed.

In my attempts to understand why, I checked the device manager and disovered that there are 2 Jlink CDC UART ports. I stubled across another ticket with another person having the same problem, so I left a note there about my same problem.

Also tried to connect with putty but no connection is made on either port.

What to do?

I guess I could try the same thing on my 52840 Dongle but am afraid that the sniffer hex file will overwrite the mbr, rendering the dongle useless unless I connect the DK debugger to it, which I prefer not to do.

What to try next?

Thanks

[Kenneth]

Blinking leds is a good sign yes.

Then it's something with the software on the PC, make sure you have installed the software mentioned in the user guide, also try a restart and close down other application that may be using the USB or com port. Try a different USB port also if possible. There is also a troubleshooting guide in the user guide.

Overall using wireshark to sniff communication should be straight forward if you follow the user guide. Hopefully you will be able to make this work soon.

Kenneth

[olgo]

Yes, I did find the troubleshooting guide but it does not handle this specific problem.

I actually already tried this on two different windows machines with the exact same behaviour.

I also tried updating to latest driver packages from Segger, no difference.

When in device manager, and no applications running, I see two UART ports and as soon as I remove the DK, both disappear. Reconnecting it immediately shows both ports again so I don't think it has anything to do with the actual applications.

Also, when testing the external interfaces for wireshark according to another guide I found online (How to install BLE Sniffer on nRF52840 Dongle and run it – JimmyIoT (jimmywongiot.com), two interfaces are indicated as opposed to the one expected.

Only thing I can think of is to try this on linux instead, but if the DK itself is causing the dual ports, I fear I will get the same problem there.

Thanks

[olgo]

Forgot to say that restarting the computers made no difference also.

Notably, both computers succeed in programming and debugging using Segger Embedded, but none can program using the nRF tool Programmer nor rfGo. I never get the possibility to Write although having erased all many times.

[Kenneth]

What software versions do you have compared to those listed in the user guide?
https://infocenter.nordicsemi.com/topic/ug_sniffer_ble/UG/sniffer_ble/min_requirements.html

Kenneth 

[olgo]

I do fulfill all the minimum requirements.

Just got a reponse from Michal in the other ticket concerning the sniffer that verifies my findings:

"

Unfortunately, there are some issues with the nRF52840 v3.0.x, because of the new interface MCU chip. They use nRF5340, while the old DKs used a Microchip IC (sam3u128).

Which is also why you cannot flash the firmware made for the old interface MCU on the new one. The firmware for the new interface MCU is not available for download at the time.

I will ask the developers about the current status, but I know that there is an issue with nRF Sniffer and a few other things not working properly on the new DKs.

"