This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Slave stops sending Empty Data PDU shortly after connection

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

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related