Client without Notifications bricking device

[Adam Gerken]

Hey everyone, I have a device that's in production and everything is working great, however we have a customer that is creating their own software to interface with our sensor and they bricked a couple units because they did not turn notifications on. This causes the unit to seemingly  wait indefinitely waiting to get the thumbs up from the client that it received the packet, which never comes. We don't expect the unit to work without notifications on, but I don't want it to lock up like this... we have no hardware reset capability so the units are junk now.

I figure there has to be an event for a time out or the like that I could use to force a disconnect and start advertising again, I just can't seem to find it. I've tied BLE_GATTC_EVT_TIMEOUT, BLE_GATTS_EVT_TIMEOUT, and BLE_GAP_EVT_TIMEOUT. None of these seem to be triggered by the sensor not being able to send a packet.

Any thoughts?

Thanks,

Adam

[Edvin]

My colleague Daniel Veilleux is right. Your transmit_samples() function never lets go. If this called from an interrupt, it will block other interrupts, because you never exit this interrupt. You should definitely consider calling this from your main loop.

I don't know what interrupt you are calling transmit_samples() from, but for the arguments sake, let's say it is a button press. How about something like this:

volatile bool transmit_samples_flag = false;

void button_press_handler()
{
    transmit_samples_flag = true;
}


...
int main(void)
{
    ...
    while (true)
    {
        if (transmit_samples_flag)
        {
            transmit_samples_flag = false;
            transmit_samples();
        }
        pwr_management_function();
    }
}

I believe you mentioned that you didn't want this kind of implementations because of current consumption. If current consumption is a concern, you should definitely break out of the:

while((err_code != NRF_ERROR_RESOURCES) && (requested_samples > transmitted_samples)){

if err_code = NRF_INVALID_STATE, because if you don't, the application will just spin through this while loop, actually never going to sleep at all.

    while((err_code != NRF_ERROR_RESOURCES) && (requested_samples > transmitted_samples)){
        
        /*FORM THE PACKET*/

        //send the packet!
        err_code = ble_ctcws_send_data(m_conn_handle, &m_ctcws, ble_packet, &packet_bytes_to_tx);
    
        //if we didn't get an error, and we're not done: incriment the number of samples and packets
        if (err_code == NRF_SUCCESS){
          transmitted_samples += (bytes_to_tx/2);
          packet_number ++;
        }
        else if (err_code != NRF_ERROR_RESOURCES)
        {
            break;  // you might as well break out of the while loop here, because if 
                    // err_code is not NRF_SUCCESS or NRF_ERROR_RESOURCES, it will not
                    // be the next time you call it either (until notifications are enabled).
        }
      }//while != NRF_ERROR_RESOURCES

BR,

Edvin