Slave stops sending Empty Data PDU shortly after connection

[cswanson420]

With good luck, I traced my connection timeout to the slave/peripheral using nrfSniffer. What is most unusual is the slave unexpectedly stops corresponding with the master regarding transmission of Empty Data PDU's. This culminates in a connection timeout error.

I am including two traces. One is from my raspberry pi and the other the nrfConnect app on a Samsung Galaxy S7 Edge. Both traces show the same behaviour.

I am using a modified version of the Blinky program in that I have a timer and an SPI circuit connected.

I have tried a few different connection parameters on my raspberry pi application which is why I am also including the nrfConnect App nrfSniffer trace since the nrf app manages its own connection parameters.

I did try to use Ozone to set a breakpoint on sd_ble_gap_disconnect() calls as outlined in devzone.nordicsemi.com/.../ but the breakpoint was never triggered. Furthermore, the only location in the code where a sd_ble_gap_disconnect() was called - in on_conn_params_evt(ble_conn_params_evt_t * p_evt) - was also never triggered.

So, my question:

Why is the slave stopping the sending of Empty Data PUD's that may be culminating in a supervisor connection timeout?

One small note of possible interest is the slave never responds to an LL_CHANNEL_MAP_REQ from the master. This is not present in all traces - that I haven't included, so it's probably not related.

ble.nrfConnect.201707011606.016.pcapng

ble.201707011606.014.pcapng

[MartinBL]

If the connection was lost due to a call to sd_ble_gap_disconnect() then that would have been evident in the sniffer trace. Since the slave just stops responding and then starts advertising again it sounds like your code is resetting. This might be due to a function returning an error which sends the code into an error handler that does a software reset of the device. Have you tried debugging as described here to figure out if any functions returns errors?

[cswanson420]

Boom. The peripheral is resetting in a call to nrf_drv_spi_transfer. If I comment this out, the connection is rock solid. The debug data was not valid though as the m_error_info struct was essentially empty. However, I was using Ozone for the determination and maybe Ozone doesn't work as well.