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

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.

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

  • Hi!

    Kazi is out of office, so I'm replying instead.

    Do you have a small example that reproduces this issue on a 52832-DK?

    What SDK version are you using ? 

    Are you using the Button handling library here?

  • hello, Sigurd

    I haven't tried running this issue on the nRF52-DK board.

    Because it is an event and TWI communication through GPIOE, I thought it would not be a HW problem.

    Is there any need to try nRF52-DK?


    The SDK in use is nRF5_SDK_17.1.0.

    The Button Handing Library is being used with some modifications.

  • Hi!

    Could you show the code where you call app_button_init() ?

  • hello.

    Relevant codes are attached.

    static void buttons_leds_init(bool * p_erase_bonds)

    uint32_t bsp_init(uint32_t type, bsp_event_callback_t callback)

    uint32_t bsp_btn_ble_init(bsp_btn_ble_error_handler_t error_handler, bsp_event_t * p_startup_bsp_evt)

    uint32_t bsp_event_to_button_action_assign(uint32_t button, bsp_button_action_t action, bsp_event_t event)

    uint32_t app_button_init(app_button_cfg_t const * p_buttons,
    uint8_t button_count,
    uint32_t detection_delay)

    uint32_t app_button_enable(void)

    void bsp_board_init(uint32_t init_flags)

  • Hi!

    I don't see anything immediately wrong in the code snippets. Is this wake-up from System ON or System OFF sleep?

    Maybe setting BUTTON_HIGH_ACCURACY_ENABLED to 1 in sdk_config.h could help

    If that does not help, then I think we would need as mentioned, a small example that reproduces this issue on a 52832-DK to dig into this further.

Reply
  • Hi!

    I don't see anything immediately wrong in the code snippets. Is this wake-up from System ON or System OFF sleep?

    Maybe setting BUTTON_HIGH_ACCURACY_ENABLED to 1 in sdk_config.h could help

    If that does not help, then I think we would need as mentioned, a small example that reproduces this issue on a 52832-DK to dig into this further.

Children
  • HI

    I think this issue was a timing issue.

    When the GPIOE signal event occurs, I2C is read almost immediately with the code below...

    /* 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);

    Currently, when a GPIOE signal event occurs, nrf_drv_twi_rx() is read after a certain time using a timer.
    It operates normally.

    I don't know if this is the exact cause...

    First of all, the operational problem was resolved.

  • pkr2258 said:
    First of all, the operational problem was resolved.

    Ok, good to hear!