This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

TWI Current Consumption

Dear All ,

I am a little stumped.... Basically first i was working with the beacon app on sdk 12 on the 51822 chip. Now I have moved to the 52382 chip.

I modified the app to run with my requirements. I added a timer to fire at every 5 seconds to check the input pin. and set advertising intervals to 10 seconds. I was getting really good current consumption of 8ua when broadcasting. and 2ua when sleeping.

But then I moved to sdk 16 and 52382 chip, only added a TWI I2c , connected to a mp121 capacitive touch sensor. All was going well until I started checking the final step of current consumption. The consumption was hitting 6ma when using the TWI(meaning sending and reading data).. which seems obsurd.... I disabled nrf Log but did not help at all. When the chip goes in a system power of mode the consumption is still hitting 70ua.

I read somewhere that the TWI' Consumption is not that high only around .5ma max when running.(I am hitting 6ma also when i just read one register)

Here is my code for twi init.

/**
* @brief UART initialization.
*/
void twi_init (void)
{
ret_code_t err_code;

const nrf_drv_twi_config_t twi_mp121_config = {
.scl = 19,
.sda = 4,
.frequency = NRF_DRV_TWI_FREQ_100K,
.interrupt_priority = APP_IRQ_PRIORITY_HIGH,
.clear_bus_init = false
};

err_code = nrf_drv_twi_init(&m_twi, &twi_lm75b_config, twi_handler, NULL);
APP_ERROR_CHECK(err_code);

nrf_drv_twi_enable(&m_twi);
}

My repeated timer which is triggered every 5 seconds:-


/**@brief Timeout handler for the repeated timer.
*/
static void repeated_timer_handler(void * p_context)
{
nrf_gpio_cfg_input(3,NRF_GPIO_PIN_PULLUP);
nrf_gpio_cfg_sense_input(3,NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_SENSE_LOW);
//readRegister8(MPR121_E0BV);
// readRegister16(MPR121_TOUCHSTATUS_L);
if(m_sample==1)//(nrf_gpio_pin_read(3)==0)
{

NRF_LOG_INFO("Button Pressed.");
advertising_stop();
advertising_init(1,0);
advertising_start();
nrf_gpio_cfg_default(23);
DelCounter=0;
}
else
{
DelCounter=DelCounter+1;
NRF_LOG_INFO("DelCounter %d.",DelCounter);
if(DelCounter>9)
{
sd_power_system_off();
}
}
}

My main:-

*/
int main(void)
{
// Initialize.
uint32_t err_code;
log_init();
NRF_LOG_INFO("Beacon example started.");
NRF_LOG_FLUSH();


timers_init();
twi_init();
MP121_set_mode();
NRF_LOG_FLUSH();
//leds_init();
create_timers();
err_code = app_timer_start(m_repeated_timer_id, APP_TIMER_TICKS(5000), NULL);
APP_ERROR_CHECK(err_code);
power_management_init();
ble_stack_init();
//sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);
advertising_init(0,0);

// nrf_gpio_cfg_input(3,BUTTON_PULL);

//nrf_gpio_cfg_sense_input(3, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_SENSE_LOW);
// APP_ERROR_CHECK(err_code);
// Start execution.

advertising_start();

// Enter main loop.

// Enter main loop.
for (;; )
{
// power_manage();
idle_state_handle();


}
}

Powe Functions:-

/**@brief Function for handling the idle state (main loop).
*
* @details If there is no pending log operation, then sleep until next the next event occurs.
*/
static void idle_state_handle(void)
{
if (NRF_LOG_PROCESS() == false)
{
nrf_pwr_mgmt_run();
}
}

/**@brief Function for doing power management.
*/
static void power_manage(void)
{
uint32_t err_code = sd_app_evt_wait();
APP_ERROR_CHECK(err_code);
}

  • So I assume you have a twi_handler() that will set m_xfer_done. And I assume you clear m_xfer_done before calling nrf_drv_twi_tx() or nrf_drv_twi_rx(). By doing this you can have a while loop after nrf_drv_twi_tx() and nrf_drv_twi_rx() that wait for m_xfer_done is set.

    I assume you are calling all nrf_drv_twi* calls from main or an interrupt context that is lower priority than the twi interrupt, else the twi_handler() will not be able to execute.

    If the TWI transfers are slower than you expect, then you should check out the actual TWI transfer using a logic analyzer (monitor the SCL and SDA pins). Have in mind though that even if the sensor is fast to sample, the serial interface is still limited to the clock speed of TWI, which may be <400kHz or lower. So 10ms may not be far off expected depending on the number of bytes and possible wait states.

    Best regards,
    Kenneth

Related