0

Feather NRF52 I2C power issue
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Feather NRF52 I2C power issue

by wb8wka on Thu Jan 31, 2019 3:46 am

Hi:

I've got two identical sketches that read a SHT31, the only difference is one uses a timer for a conditional to read it once every 1500ms, the other has a 1500ms delay after the conditional. Both end with "WaitForEvent()". One would think the conditional test would draw less power, but it is 6 times here. Here are code snippets and power drain measured at the battery in (3.6 volts) on the feather board. I also have just beacon code (no I2C read) that is in the 110ua range. The code is based on the beacon sample with the loop modified.

The code works in all three cases, just the combination of a I2C read and the millisecond timer conditional test seems to make the current skyrocket. Any hints on where to look?

Conditional read based om millisecond timer, 2 second BLE beacon, test valid every 1500ms
3076 ua average on stock Feather NRF52 board, 3.6 vlts into battery connector
Code: Select all | TOGGLE FULL SIZE
void loop()
{
  // loop is already suspended, CPU will not run loop() at all
  unsigned long currentMillis = millis();     // Check the time on each loop

  if(currentMillis - previousMillis > INTERVAL)
  {   
    previousMillis = currentMillis;     // save the last time   
 
    temperture = (unsigned int)sht31.readTemperature();
    //humidity = (unsigned int)sht31.readHumidity();

    ABTemp = (humidity << 8) + (temperture & 0xFF);
    BLEBeacon beacon(beaconUuid, temperture, ABTemp, -70);


  // Advertising packet
  // Set the beacon payload using the BLEBeacon class populated
  // earlier in this example
    Bluefruit.Advertising.setBeacon(beacon);
    Bluefruit.Advertising.start(0);       
  }
 
  sd_power_mode_set(NRF_POWER_MODE_LOWPWR);
  waitForEvent();
}


Based on delay, 2 second BLE beacon, delay is 1500ms
547 ua average on stock Feather NRF52 board, 3.6 vlts into battery connector
Code: Select all | TOGGLE FULL SIZE
void loop()
{
  // loop is already suspended, CPU will not run loop() at all

    temperture = (unsigned int)sht31.readTemperature();
    //humidity = (unsigned int)sht31.readHumidity();

    ABTemp = (humidity << 8) + (temperture & 0xFF);
    BLEBeacon beacon(beaconUuid, temperture, ABTemp, -70);
 
    delay(1500);     


  // Advertising packet
  // Set the beacon payload using the BLEBeacon class populated
  // earlier in this example
    Bluefruit.Advertising.setBeacon(beacon);
    Bluefruit.Advertising.start(0);     

  sd_power_mode_set(NRF_POWER_MODE_LOWPWR);
  waitForEvent();
}



Beacon code, Beacon set to 2 seconds, loop conditional executes every 1500ms
118ua average on stock Feather NRF52 board, 3.6 vlts into battery connector
Code: Select all | TOGGLE FULL SIZE
void loop()
{
  // loop is already suspended, CPU will not run loop() at all

  unsigned long currentMillis = millis();     // Check the time on each loop

  if(currentMillis - previousMillis > 1500)
  {   
    previousMillis = currentMillis;     // save the last time   
         
 /***** test code section ****/
    digitalWrite(LED_BUILTIN, HIGH);
    delay(1);
    digitalWrite(LED_BUILTIN, LOW);
    temperture = temperture + 1;
    humidity = humidity + 1;

    if (temperture == 99)
    {
        temperture = 0;
    }

    if (humidity == 99)
    {
        humidity = 0;
    }
    ABTemp = (humidity << 8) + (temperture & 0xFF);

    BLEBeacon beacon(beaconUuid, temperture, ABTemp, -70);


 
  // Advertising packet
  // Set the beacon payload using the BLEBeacon class populated
  // earlier in this example
    Bluefruit.Advertising.setBeacon(beacon);
    Bluefruit.Advertising.start(0);     //***JK this was 1 before
   
  }

  sd_power_mode_set(NRF_POWER_MODE_LOWPWR);
  waitForEvent();
}

wb8wka
 
Posts: 45
Joined: Fri Sep 21, 2018 5:09 pm

Re: Feather NRF52 I2C power issue

by wb8wka on Thu Jan 31, 2019 4:13 am

Could this be possible lead? I2C drawing more current in sleep mode?

https://github.com/sandeepmistry/arduin ... issues/291

wb8wka
 
Posts: 45
Joined: Fri Sep 21, 2018 5:09 pm

Re: Feather NRF52 I2C power issue

by jpconstantineau on Mon Feb 04, 2019 9:30 am

The loop with the if statement will run "as fast as possible" and every time is passes through the if statement, check if I2C "work" is needed: 3000uA, not surprising. CPU is running most of the time.

The loop with the if statement and a delay of 1ms will run once every 1 ms.: 120uA. not surprising since it's no longer running all the time. I believe this is in sync with "systick".

The code with just the loop with a delay will essentially run the loop once every 1500ms. 550uA. Surprising since it should be pretty much be sleeping in between loops.

I too have observed odd behavior when designing for low power. Apparent small changes that one would think would improve consumption actually do the reverse.

How much more overhead does FreeRTOS take when managing tasks?

jpconstantineau
 
Posts: 34
Joined: Tue Nov 13, 2018 12:30 pm

Re: Feather NRF52 I2C power issue

by wb8wka on Tue Feb 05, 2019 3:54 am

jpconstantineau wrote:The loop with the if statement will run "as fast as possible" and every time is passes through the if statement, check if I2C "work" is needed: 3000uA, not surprising. CPU is running most of the time.

The loop with the if statement and a delay of 1ms will run once every 1 ms.: 120uA. not surprising since it's no longer running all the time. I believe this is in sync with "systick".

The code with just the loop with a delay will essentially run the loop once every 1500ms. 550uA. Surprising since it should be pretty much be sleeping in between loops.


No, you have mixed them up. Loop with if statement testing every 1500ms has either I2C read (3076ua) or flash LED (108ua). So massive difference just because of IC2 statement.

With delay of 1500ms instead of test, I2C average is 547ua.

Yes, that was surprise since hatech said that "delay(0)" is just like sleep, but it is not. Please see my trouble report here which Adafruit had no time to debug

viewtopic.php?f=57&t=146147

wb8wka
 
Posts: 45
Joined: Fri Sep 21, 2018 5:09 pm

Re: Feather NRF52 I2C power issue

by jpconstantineau on Tue Feb 05, 2019 11:30 am

I see. That's quite the major difference with I2C.

Does the library use the I2C peripheral or use bit-banging? I hope it uses the peripheral. If not, that would explain the excessive power needs.

jpconstantineau
 
Posts: 34
Joined: Tue Nov 13, 2018 12:30 pm

Re: Feather NRF52 I2C power issue

by wb8wka on Tue Feb 05, 2019 6:58 pm

Whatever the wire library uses, which I assume is the peripheral. That's actually a interesting thought, if I were to bit bang the I2C maybe that would get my current down? I'm "bit banging" the LED and there is no hit on power consumption to speak of (I leave it on 1ms).

wb8wka
 
Posts: 45
Joined: Fri Sep 21, 2018 5:09 pm

Re: Feather NRF52 I2C power issue

by pcaddict on Tue Feb 05, 2019 7:42 pm

From my readings, the correct way to get into low power mode when using a peripheral such as i2C or SPI is to disable and uninitialize the peripheral when you are not using it. There is also an eratta related to the nrf52832 and nrf52840 (PAN_89) that mentions high current consumption during idle when using the aforementioned peripherals. After disabling and uninitializing I2C you need the following bit of code:

Code: Select all | TOGGLE FULL SIZE
*(volatile uint32_t *)0x40003FFC = 0;
*(volatile uint32_t *)0x40003FFC;
*(volatile uint32_t *)0x40003FFC = 1;


See here.

pcaddict
 
Posts: 52
Joined: Thu Aug 31, 2017 9:24 pm

Re: Feather NRF52 I2C power issue

by wb8wka on Tue Feb 05, 2019 7:48 pm

Thanks, so then each cycle through the loop i would initialize the IC2, use it, then deinitialize it when done?

On that point, I did seem to notice a "latch function" with current... with the longer I2C delays (such as 10 seconds) everything would start out fine.... then 10 seconds later on the first read the current would go high (which is expected in the few 10's of MS he I2C is reading) but then just stay high no matter what.

What caused me not to try this, is I didn't see this with the delay function. I had seen some of what you referred to. I'll try that later tonight and report back.

wb8wka
 
Posts: 45
Joined: Fri Sep 21, 2018 5:09 pm

Re: Feather NRF52 I2C power issue

by pcaddict on Tue Feb 05, 2019 7:58 pm

From what I can tell from Nordic support, yes, you have to initialize, read your sensor, then deinitialize every cycle. The support case I saw said this should be done after every transaction, but that seems like overkill.

I have not tried this yet, but if you keep power on your sensor, it should maintain its configuration internally, so the cycle of initialize, read sensor, then deinitialize I2C should not have an effect timing wise with having to run the init sequence on your temp sensor. *I think*

pcaddict
 
Posts: 52
Joined: Thu Aug 31, 2017 9:24 pm

Re: Feather NRF52 I2C power issue

by p2w on Wed Feb 06, 2019 7:06 am

Caveat Emptor: I2C is notorious for its reset-problem. If you for whatever reason stop halfway through its communication cycle, the peripheral's internal statemachine won't be reset. Therefore, it is advisable to execute a "reset" (9 cycles of the clock, followed by a stop condition) to make sure the statemachine is in a known state. If you shut down the I2C peripheral after each measurement, this introduces quite some overhead.

Depending on the mechanism used for data transfer, nRF52 may use a lot of current. EasyDMA is one known cause (someone mentioned 1,5 mA) and if I recall correctly the nRF52 "wire" library actually uses that (haven't checked the details...). Would be interesting to see what a bit-banged method would take.

p2w
 
Posts: 66
Joined: Fri Dec 15, 2017 5:29 am

Re: Feather NRF52 I2C power issue

by pcaddict on Wed Feb 06, 2019 11:17 pm

Found an interesting papercomparing the use of peripherals and software implementations. I realize it is somewhat old but I imagine their findings (page 5 for the good stuff) transfer to just about any platform.

TLDR: bit-banging i2c used 2-2.5 times more energy.

pcaddict
 
Posts: 52
Joined: Thu Aug 31, 2017 9:24 pm

Re: Feather NRF52 I2C power issue

by p2w on Thu Feb 07, 2019 8:20 am

pcaddict wrote: I imagine their findings (page 5 for the good stuff) transfer to just about any platform.

TLDR: bit-banging i2c used 2-2.5 times more energy.


I very much doubt that this figure is valid on other platforms. It also depends on what the CPU is doing when it is not transferring data and it depends heavily on the implementation details.

p2w
 
Posts: 66
Joined: Fri Dec 15, 2017 5:29 am

Re: Feather NRF52 I2C power issue

by wb8wka on Wed Feb 13, 2019 6:55 pm

@pcaddict

No joy. I inserted this:

Code: Select all | TOGGLE FULL SIZE
// Shut down I2C   
  Wire.end();
  NRF_TWI1->ENABLE  = (TWI_ENABLE_ENABLE_Disabled << TWI_ENABLE_ENABLE_Pos);
  NRF_TWI0->ENABLE  = (TWI_ENABLE_ENABLE_Disabled << TWI_ENABLE_ENABLE_Pos);   
  *(volatile uint32_t *)0x40003FFC = 0;
  *(volatile uint32_t *)0x40003FFC;
  *(volatile uint32_t *)0x40003FFC = 1;


And had little effect.

wb8wka
 
Posts: 45
Joined: Fri Sep 21, 2018 5:09 pm

Re: Feather NRF52 I2C power issue

by pcaddict on Wed Feb 13, 2019 6:58 pm

You don't happen to be doing any floating point math anywhere do you?

pcaddict
 
Posts: 52
Joined: Thu Aug 31, 2017 9:24 pm

Re: Feather NRF52 I2C power issue

by wb8wka on Wed Feb 13, 2019 7:01 pm

Yes, the SHT31 library does do floating point. It could be modified not to. Is there a issue here?

wb8wka
 
Posts: 45
Joined: Fri Sep 21, 2018 5:09 pm

Please be positive and constructive with your questions and comments.