First, some background info. I'm using a modified version of the 5.0.2.1 SDK's ble_app_peripheral example. I'm running one custom service, adapted from user_custs1. I'm running the DA14580 as a standalone MCU that communicates with another MCU over UART. The DA14580 primarily functions as a relay that takes packets and sends them over BLE, and receives packets and sends them over UART. The DA14580 also sends packets to the second MCU to inform it of BLE state changes (connect, disconnect, etc) .
The problem that I'm seeing is that if I start sending data from the DA14580-based system to another BLE device and carry that device out of range, the BLE connection will drop but the DA14580 doesn't seem to realize it. The DA14580 doesn't start advertising again, and it never notifies the second MCU of the disconnect event. If I'm not streaming any data over BLE, then the connection drop is properly recognized.
Any ideas? I'm informing my second MCU of disconnect events within the gapc_disconnect_ind_handler() function in custs1_task.c.
Hi jzahn,
I dont fully understand if the configuration is fully embedded or fully hosted. I suppose that is a fully hosted device, when disconnected either from exceeding range or disconnection by the host the handler that is triggered is the same, user_app_disconnect(). Please check that this is the handler that is triggered in both cases (dont use sleep and place a break point in order to confirm it). Also in order for the device to restart advertising there is a condition that instructs the application to start advertising if the application's state is at a specified state, you can check this condtion as well, perhaps the state of your device is different. Also check that after the user_app_disconnect() the gapc_disconnect_ind_handler() is triggered in the custs1_task.c. In the ble_app_peripheral, both of the disconnect functions should be called in both cases.
Thanks MT_dialog
Hey MT_dialog,
To clarify, I'm running the DA14580 as a standalone cortex M0 with BLE, and using an application on it to talk to another standalone cortex M3.
I've tried using the user_app_disconnect() callback to detect a disconnect, but that callback also does not get called. If I cleanly terminate the BLE connection, both the user_app_disconnect() and the gapc_disconnect_ind_handler() handler are called, in that order.
I ran a few more tests, and if I'm not sending more than about two 20 byte packets per second, then an out-of-range disconnect is properly recognized. If I send data more frequently than that, the out-of-range disconnect is not recognized.
Is there a lower level of the stack that might recognize the disconnect that I could try to hook into?
I just did a test with another device we have that's using the DSPS profile, and I see what looks like the same issue. If data is actively being streamed at maybe 2Hz or faster, and the connected device goes out of range, the system does not go back to the advertising state. I don't have debug access to that device so I can't confirm exactly what's going on, but the symptoms are the same.
Hi jzahn,
Now that you ve given me some more info regarding your application i assume that when going out of range your device resets. I suppose that you are allocating too much data and when going out of range and those data are accumulated, flood your heap and the 580 goes in platform reset. You have to use a kind of a flow control about this, perhaps before sending the next notification wait for the confirmation that the previous notification was sent succesfully.
Thanks MT_dialog
Success!
I set a flag within user_custs1_b_data_ntf_cfm_handler() in user_custs1_impl.c to make sure that a new BLE notification isn't submitted unless the previous one has been confirmed, and my issue has been fixed.
Thanks for the help MT_dialog, you've saved me lots of time and sanity.