Problem with initial operation not working when transmitting TWI after wake-up by GPIOTE

hello,

We are implementing the function of sending/receiving via TWI after wake-up by GPIOTE.

The problem is after wake-up by GPIOTE....

The first TWI transmission/reception does not work. (No specific error is returned... only the waveform cannot be observed from the actual port.)

And in the operating state, TWI transmission/reception works normally from the second GPIOTE signal.

SW configuration is

wake-up by GPIOE -> void bsp_event_handler(bsp_event_t event) ->  app_timer_start(m_eventTWI_timer_id, EVENT_TWI_MEAS_INTERVAL, NULL);

-> static void eventTWI_timeout_handler(void * p_context) ->  read_sensor_data() -> Run nrf_drv_twi_rx

void bsp_event_handler(bsp_event_t event)
{
    uint32_t err_code;
    uint8_t mBLE_Send_check = 0;
    printf("> bsp_EH ");

    switch (event)
    {

        case   BSP_EVENT_ADVERTISING_STOP :
         
            printf("> BSP_EVENT_ADVERTISING_STOP\r\n");
           

            break;

       
        case BSP_EVENT_KEY_0 :

            printf("eTouch\r\n");

            m_eventTWI_timer_cnt = 0;
            err_code = app_timer_start(m_eventTWI_timer_id, EVENT_TWI_MEAS_INTERVAL, NULL);
            APP_ERROR_CHECK(err_code);

            //err_code = nrf_drv_twi_tx(&m_twi, PIC_TOUCH_ADDR, TWI_reg, sizeof(TWI_reg), false);
            //PIC_TOUCH_set_mode();
           

            mBLE_Send_check = 1;
           
             break;
   }
}
 

static void eventTWI_timeout_handler(void * p_context)
{
   
    //PIC_TOUCH_set_mode();
    //nrf_delay_us(500);
   
    m_eventTWI_timer_cnt++;
    printf("> TWI_tEH %d\n\r", m_eventTWI_timer_cnt);
    UNUSED_PARAMETER(p_context);

   
     if( m_eventTWI_timer_cnt <= 1 )
     {
        read_sensor_data();
     }
     else
     {
        //m_eventTWI_timer_cnt = 0;    
        app_timer_stop(m_eventTWI_timer_id);    
     }
}

static void read_sensor_data()
{
    m_xfer_done = false;
    uint8_t temp_key = 0;

    /* Read 1 byte from the specified address - skip 3 bits dedicated for fractional part of temperature. */
    ret_code_t err_code = nrf_drv_twi_rx(&m_twi, PIC_TOUCH_ADDR, &m_PIC_Touch_data[0], sizeof(m_PIC_Touch_data) );
    APP_ERROR_CHECK(err_code);
}

After wake-up, there was no effect even if the Timer delay was greatly increased to 500ms or more.

Please check if the first TWI does not run after wake-up.

-----------------------------------------------------------------------------------------------------------------------------------------------------

Additionally, what was discovered during the experiment was

The role of the PCB that currently runs TWI is peripheral, but the above phenomenon is reproduced when it is not connected to central.

However, when connected to central... the problem of not being able to run TWI the first time above disappears.

It operates normally from the first TWI.

  • Hello,

    If you wake up by GPIOTE, then the system should have been in SystemOn, that is what most of our chips do. 

    Can you please check the scope of the lines to see if there is any activity?

    If you do a second call to read_data_sensor function, will it then work?

    Which pins you are using for TWI and for wakeup?

    Thanks.

    BR

    Kazi

  • hello,

    Thank you for your reply.

    Which pins you are using for TWI and for wakeup?

    GPIOTE : P0.03 

    TWI  CLK : P0.9

    TWI  DAT : P0.10

    ->  P0.9 / P0.10 are pins whose default is NFC, so they were set separately as GPIO.

    .

    If you do a second call to read_data_sensor function, will it then work?

    .

    Currently, the PCB using TWI is Peripheral, and we would like to inform you once again that the above symptoms occur without connection to the Central.

    .

    In the read_sensor_data() function, I tried forcing the Run nrf_drv_twi_rx function to run twice with a delay of over 10ms.

    Still, after wake-up, the first TWI does not generate a signal.

    .

    Under current conditions, 

    It occurs in the second GPIOTE... My guess is that the TWI signal is generated because it occurred during wake-up from sleep.

    .

    But the unusual situation is...

    When connected to Central, the TWI signal comes out normally from the first GPIOTE.

    .

    .

    1. The moment of wake-up from sleep by GPIOTE when not connected to cental.

     1.1. TWI signal occurs from the second time after the first GPIOTE signal.

    .

    1.2. This time, the GPIOTE signal occurred 4 times, but the TWI signal did not occur even once.

    .

    1.3. This time, TWI occurred in the third GPIOTE signal.

    .

    2. TWI waveform after GPIOTE generation in operating state: TWI signal occurs normally from the first GPIOTE signal.

    .

    3. Twi waveform after wake-up by GPIOTE from sleep in central and connection state

    3.1. After connection, when entering the sleep state and immediately inputting the GPIOTE signal, the twi signal occurs normally.

    .

    4. In the connected state, the twi signal by GPIOTE is generated normally, but in the actual data, the order of twi is changed and read.

    Normally, twi 2 occurs for GPIOTE 2.

    .

    First, twi data by GPIOTE - 0x40 / 0x00 / 0x00

    .

    Second, twi data by GPIOTE - 0x00 / 0x00 / 0x00

    .

    Looking at the waveform above, the data sent from the slave is 0x40 / 0x00 / 0x00 -> 0x00 / 0x00 / 0x00.

    .

    As shown below, in read_sensor_data()

    ble_nus_data_send(&m_nus, gBLE_Data_key, &gLen_gBLE_Data_key, m_conn_handle);

    If you add a function and check the data in central, there is something unusual.

    static void read_sensor_data()
    {
    m_xfer_done = false;
    
    gBLE_Data_key[0] = 0;
    
    /* Read 1 byte from the specified address - skip 3 bits dedicated for fractional part of temperature. */
    ret_code_t err_code = nrf_drv_twi_rx(&m_twi, PIC_TOUCH_ADDR, &m_PIC_Touch_data[0], sizeof(m_PIC_Touch_data) );
    APP_ERROR_CHECK(err_code);
    
    
    
    :
    
    :
    
    do
    {
    err_code = ble_nus_data_send(&m_nus, gBLE_Data_key, &gLen_gBLE_Data_key, m_conn_handle);
    if ((err_code != NRF_ERROR_INVALID_STATE) &&
    (err_code != NRF_ERROR_RESOURCES) &&
    (err_code != NRF_ERROR_NOT_FOUND))
    {
    APP_ERROR_CHECK(err_code);
    }
    
    } while (err_code == NRF_ERROR_RESOURCES);

    * actual waveform :  0x40 / 0x00 / 0x00 -----> 0x00 / 0x00 / 0x00.

    *Data received from central : 0x00 / 0x00 / 0x00. ----> 0x40 / 0x00 / 0x00

    The first and second data are received in reversed order.

    Due to the structure of the program, it is normal to receive it from central in the order of the actual waveform... What is the reason?

    .

    .

    .

    .

    as a result

    When not connected to central, twi is not generated after wake-up by GPIOTE.

    When connected to central, the order of twi data generated by GPIOTE is changed, so I do not understand why it is received at central.

  • Hello,

    GPITE signal looks too short. You can try to debug the code to see if the handler is actually called and TWI functions are actually called? You are using BSP, which has 50ms detection delay by default for buttons in order to avoid button debounce, signal issues etc.

  • hello, 

    I am receiving debugging messages for the above behavior.

    Therefore, it was confirmed that normal wake-up occurred for the GPITE signal.


    The actual wake-up occurs normally without any omissions.

    The TWI signal is not generated...

    and

    Do you have any idea why it depends on whether you are registered or not?

    thank

  • Hello,

    ''I am receiving debugging messages for the above behavior.''

    Could you please share the debug output?

Related