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

Power Consumption rises after I2C data transfer

I am using the zephyr rtos which run on the nrf52832. 

Describe the bug
We are using a nrf52832 based board. There are some I2C devices like tsm12 and eeprom.
The power consumption is 200ua when the I2C buses of the nrf52832 is enabled, but without data transfering.
But when data transfer throw the I2C bus, the power consumption of the board increased by about 400ua.
The power consumption will never fall back again, even when the data transfering is over.

What have you tried to diagnose or workaround this issue?

  1. When the issue is taking place, i have tried to disconnect the physical connection of all the i2c devices
    included the tsm12 and the eeprom. But it is useless. So the increase of the power consumption issue is caused
    by the chip of nrf52832.
  2. But the i2c driver of nrf52832 has disabled the i2c bus after data transfering by calling this function:
    "nrfx_twim_disable(&get_dev_config(dev)->twim);" . So it seems that the power consumption issue is not caused by
    the i2c bus of the nrf52832.
  3. Then i tried to disable all the interupts of the i2c bus of the nrf52832. The issue does not take place.
  4. I tried to delete the calling of the function : k_sem_take(&(get_dev_data(dev)->completion_sync),
    I2C_TRANSFER_TIMEOUT_MSEC). The issue does not take place.
  5. So it seems that the interupts conflict with this function:k_sem_take. Maybe the interupts affect the power saving
    strategy of the kernel
    .

To Reproduce
Steps to reproduce the behavior:

  1. Find a nrf52 based board with some i2c devices
  2. run the sample
  3. Test the power cosumpertion
  4. A nrf52832 based board without a i2c device is also can be used to reproduce the issue. Becase the errors can also
    trigger an interupt.
Parents
  • Hi

    This seems to be the erratum 89 that is causing this excess current consumption, as the workaround has not been implemented in Zephyr, but rather in our nRFConnect SDK. After TWIM is finished operating it's necessary to power cycle the peripheral to disable it correctly. We recommend doing a full uninitializing of the module through Zephyr before you power cycle it though.

    There is also a workaround that won't require a power cycling of the peripheral which enables TWIS for a short amount of time before enabling TWIM again.

    temp = NRF_TWIMx->ENABLE 
    NRF_TWIMx->ENABLE = 9 
    NRF_TWIMx->ENABLE = temp 

    The official workaround should be sufficient as well which is described in the erratum link I provided at top.

    Best regards,

    Simon

Reply
  • Hi

    This seems to be the erratum 89 that is causing this excess current consumption, as the workaround has not been implemented in Zephyr, but rather in our nRFConnect SDK. After TWIM is finished operating it's necessary to power cycle the peripheral to disable it correctly. We recommend doing a full uninitializing of the module through Zephyr before you power cycle it though.

    There is also a workaround that won't require a power cycling of the peripheral which enables TWIS for a short amount of time before enabling TWIM again.

    temp = NRF_TWIMx->ENABLE 
    NRF_TWIMx->ENABLE = 9 
    NRF_TWIMx->ENABLE = temp 

    The official workaround should be sufficient as well which is described in the erratum link I provided at top.

    Best regards,

    Simon

Children
Related