Timer does not work and pairing is disconnected.

[powerup]

Hi.

I have an experience that I do not understand.

<main>

if(pushSwitch == true){
    waitSwitch_flag = true;
    waitSwitch_cnt = 0;
    
    while(pushSwitch == true){ 
      nrf_delay_ms(10);
      if(waitSwitch_cnt >= 50) break;
    }
    
    waitSwitch_flag = false;
    
    if(waitSwitch_cnt < 20){
        printf("2s\r\n");
    }
    else if(waitSwitch_cnt >= 50){
        printf("5s\r\n");
    }
}

<timer handler>

void timer_event_handler(nrf_timer_event_t event_type, void* p_context){

    switch (event_type)
    {
        case NRF_TIMER_EVENT_COMPARE0:
            if(waitSwitch_flag == true){
              waitSwitch_cnt++;
            }
            break;
            
        default:
            break;
    }
}

• "PushSwitch" changed to true when the button was pressed using a switch interrupt.
• While pressing the button, measure the time on the timer.

1. If there is no delay in the while statement, the time is not counted.
   Even if the button is held down for a long time, only "2s" is output.
2. When I press and release the button, the pairing connection is lost.
   It does not always disconnect.

It is strange that it works differently depending on whether there is a delay or not, and suddenly it does not understand that the pairing is cut off.

Do you have the same problem or do you know the cause?

Thank you.

[Einar Thorsrud]

Hi,

There are a few important pieces of your code missing in the post:

• We do not see how you declare waitSwitch_cnt. Is it volatile? If not, then it might not be read when you think it is, depending on the optimization level. In that case, it might always be send as having the value 0 in main even though it have been incremented in timer_event_handler().
• I assume, due to the <main> heading above the code snippet that it is called from the main function, which is in main/thread mode. if it is not, and happens to run with the same interrupt priority as timer_event_handler(), then you might also see this problem.

Now for the questions:

1. Where does pushSwitch come from? If it is updated on the fly based on the button state, and this does not have debouncing, then it might be that it is noisy so that it will become false again almost immediately. This is only speculation without know where it comes from.

2. Can you elaborate on what you mean by pairing connection is lost / cut off? Is the BLE connection terminated? Or something else? What do you mean by peering in this regard? I do not see how this can affect pairing/bonding information, but I might be lacking context since I only see a few snippets of your code. Please elaborate.

[powerup]

1. 

uint8_t waitSwitch_cnt = 0; 
bool pushSwitch          = false;

Both are declared as global variables.

For waitSwitch_cnt, it always goes to 0 if there is no delay.

static void interrupt_configure(void){
    ret_code_t err_code;

    err_code = nrf_drv_gpiote_init(); 
    APP_ERROR_CHECK(err_code);

    nrf_drv_gpiote_in_config_t in_config = NRFX_GPIOTE_CONFIG_IN_SENSE_TOGGLE(true);
    in_config.pull = NRF_GPIO_PIN_PULLUP;

    nrf_drv_gpiote_in_init(BUTTON_1, &in_config, in_pin_handler0);
    
    nrf_drv_gpiote_in_event_enable(BUTTON_1, true); 
    //nrf_drv_gpiote_in_event_disable(BUTTON_1);
}
void in_pin_handler0(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action){
  
    nrf_drv_gpiote_in_event_disable(BUTTON_1);
    nrf_delay_ms(40);
    
    if(nrf_gpio_pin_read(BUTTON_1) == 0){
        pushSwitch = true;
        
    }
    else if(nrf_gpio_pin_read(BUTTON_1) == 1){
        pushSwitch = false;
    }   

    nrf_drv_gpiote_in_event_enable(BUTTON_1, true);
}

2.

The BLE_GAP_EVT_DISCONNECTED event is raised and the connection is lost.

I do not speak English well, so please understand that I do not have enough explanation.
I will provide all the necessary information.

[Einar Thorsrud]

Hi,

1. The pushSwitch must be volatile for this to work with optimization. You should declare it like this:

volatile bool pushSwitch = false;

Does that fix the issue? If it does not solve the problem, then you have another issue as well and it would be useful to see more of your code to try to get a better understanding of it.

2. I do not immediately see why there is a disconnect.  You could start by looking at the disconnect reason (something like p_gap_evt->params.disconnected.reason) when you get a BLE_GAP_EVT_DISCONNECTED event.

[powerup]

Thank you.
I will try the methods you have given me.

One more question about BLE data transfer.

length = strlen("1");
err_code = ble_nus_data_send(&m_nus, "1", &length, m_conn_handle); 
while (err_code == NRF_ERROR_BUSY);
//nrf_delay_ms(20);
length = strlen("2");
err_code = ble_nus_data_send(&m_nus, "2", &length, m_conn_handle); 
while (err_code == NRF_ERROR_BUSY);
//nrf_delay_ms(20);
length = strlen("3");
err_code = ble_nus_data_send(&m_nus, "3", &length, m_conn_handle); 
while (err_code == NRF_ERROR_BUSY);
//nrf_delay_ms(20);
length = strlen("4");
err_code = ble_nus_data_send(&m_nus, "4", &length, m_conn_handle); 
while (err_code == NRF_ERROR_BUSY);
//nrf_delay_ms(20);
length = strlen("5");
err_code = ble_nus_data_send(&m_nus, "5", &length, m_conn_handle); 
while (err_code == NRF_ERROR_BUSY);
//nrf_delay_ms(20);

When sending data continuously as above, if there is no delay, data is missing.
What should I do in the middle of sending data?

Thank you.

[Einar Thorsrud]

Hi,

A busy wait with nrf_delay_ms() is OK for a simple test, but the proper way to handle this is to try to send data until you get NRF_ERROR_BUSY. In that case you should wait for a BLE_GATTS_EVT_HVN_TX_COMPLETE event before trying to send more data.