NRF9160 Deep Sleep Power Consumption Help

Hello,

I am using mfw1.3.0 and NCS 1.7.0 developing an application on a custom board implementing the NRF9160 and NRF52820 (The 52820 is put into very low power using nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_STAY_IN_SYSOFF);). 

There is a state in the application where we would like the device to go into a deep sleep mode where the device ideally consumes <200uA of current (Lower is even better). The device is awoken by a state change on a configured Sense pin. 

In the current stage of development, everything is working decently well with the modem powering off and then the device being set to deep sleep. The issue is that we are seeing around 900uA of average current draw (It seems to be fluctuating between about 500uA and 1200uA). I know some of this current is due to on-board peripheral parts drawing a bit of power but it really should only be accounting for around 150uA or so and is something we are working on separately.

I have read pretty much every post out there about low power mode on the NRF9160 and it seems that the first thing to check is if CONFIG_SERIAL is disabled in both the application config as well as the SPM config. Our application will be using serial but we want to shut it down before going into deepsleep with this function: 

pm_device_state_set(uart_0_dev, PM_DEVICE_STATE_OFF);
This behavior is found in the serial_lte_modem example. The problem is that using this line to disable uart seems to have no effect on current draw.
I also tried just not using serial at all in the application and ensuring that CONFIG_SERIAL is not set in either the application config or SPM config. This also did not have any affect which was surprising to me and leads me to believe that there is another peripheral that we have enabled which is causing the same current draw that having the serial peripheral does.
My questions that can't be answered by other tickets are:
1. What is the real reason that turning serial off saves power in deep sleep? From looking at other tickets I think that the root cause of the power draw is keeping the HF clock active in deep sleep which can draw a decent amount of current.
2. Are there other peripherals that could be causing the same issue for us still? We use I2C, SPI, UART, PWM, and GPIO in the application.
3. What is the best way to have serial enabled in the application but turn the peripheral off before sleeping in NCS1.7.0 and mfw1.3.0?
Also, we have tried with mfw1.3.1 which supposedly has a fix for a deep sleep power issue but that has no affect. 
Thanks!
Tyler
Parents
  • Ok, Thank you for the information. The fact that it would cause a 500-600 uA draw makes me think UART may not be the issue. Here is a rough capture of the best sleep current we have gotten so far where 1mv = 1uA: 

    It seems the lower level current is in the 300-400uA range. Most of this is likely caused by other peripherals on the PCB that are consuming power.

    One other note is that we are using the SICA-B1A revision of the 9160. I am unsure if this new revision could change sleep current consumption etc.

    Thanks,

    Tyler

  • Thanks. So that's definitely not the regulator in refresh mode as I mentioned in my last reply. Looks like something is being polled every ~50ms. But, if the nRF91 CPU is waking up I would expect the current to be higher.

    It could be the PWM. Is it enabled?

    Are you sure the nRF91 is causing this? It could be an external sensor or similar, if you have that.

    You are also welcome to send me your board for further debugging, but because of new covid regulations access to the office/lab is restricted at least the next two weeks, so it would have to wait probably until after Christmas. If you choose to do so please create a new private ticket and mention my name.

Reply
  • Thanks. So that's definitely not the regulator in refresh mode as I mentioned in my last reply. Looks like something is being polled every ~50ms. But, if the nRF91 CPU is waking up I would expect the current to be higher.

    It could be the PWM. Is it enabled?

    Are you sure the nRF91 is causing this? It could be an external sensor or similar, if you have that.

    You are also welcome to send me your board for further debugging, but because of new covid regulations access to the office/lab is restricted at least the next two weeks, so it would have to wait probably until after Christmas. If you choose to do so please create a new private ticket and mention my name.

Children
No Data
Related