System Off mode and powered peripherals

[Andrea Verdecchia]

Is it safe to connect the communication peripherals (SPI, UART, I2C, etc.) of an nRF52840 in system_off state to powered peripherals that might (or not) possibly transmit data?

[Priyanka]

Hi Andrea,

When in system_off mode, the internal circuitry of the chip aims to minimize the power consumption and the pins will be in a high-impedance state. So in case you connect them to powered peripherals and they transmit data, this can cause anomalous behaviour and also possible current leakage due to the high-impedance. Sometimes this can also cause backfeeding from the powered peripherals to the chip and can cause problems since the chip would be in partial operation in the system_off state. So it would be better to not connect them to powered peripherals. In case it's unavoidable, then maybe you could add some external protection circuit or even series resistors before connecting them to the powered peripherals. 

Regards,

Priyanka

[Andrea Verdecchia]

Hi Priyanka,
I still have a couple of questions:

1. I am looking at the Zephyr example on the system_off mode, which is compatible with the nRF52840 DK development board. In this case, the code, before activating the system_off mode, only configures the interrupt on the pin for wake-up and disables the UART (for the console) by calling the function pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND). However, on the development board, if I understand the schematic correctly, the nRF52840 chip remains connected via UART to the nRF5340 interface chip, which stays active. In this case, is there any problem, or am I missing something?

2. In my case, the only bus that would remain active on my nRF52840 in system_off mode would be an I2C that has pull-ups on the VDD power supply. The active peripheral would still be a slave, and since the SDA and SCL signals are open-drain on the ports of my sleeping nRF52840, I would only have a pull-up to VDD. Could this be a problem?

I hope I explained myself well.

[Priyanka]

Hi Andrea,

Andrea Verdecchia said:

In this case, the code, before activating the system_off mode, only configures the interrupt on the pin for wake-up and disables the UART (for the console) by calling the function pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND).

Yes that's right. This is done to reduce power consumption, as the UART peripheral can contribute significantly to idle current.

Andrea Verdecchia said:

However, on the development board, if I understand the schematic correctly, the nRF52840 chip remains connected via UART to the nRF5340 interface chip, which stays active. In this case, is there any problem,

That's also right. This connection will not be a problem for the system_off mode of the nRF52840, because when it enters system_off mode, it will shut down most of its circuitry, including the UART peripheral, so the physical connection to the interface chip won't cause any issues or prevent the nRF52840 from entering its lowest power state. But please see here that UART is an exception that needs to be handled explicitly by the application for power management.

Andrea Verdecchia said:

In my case, the only bus that would remain active on my nRF52840 in system_off mode would be an I2C that has pull-ups on the VDD power supply. The active peripheral would still be a slave, and since the SDA and SCL signals are open-drain on the ports of my sleeping nRF52840, I would only have a pull-up to VDD. Could this be a problem?

That should be fine then. If the other device is a slave, it will not do anything unless it receives an I2C command, which it will not receive if the nRF is in system off.
 But keep in mind that you may want to disable the peripheral to save power. High impedance pins doesn't draw a lot of power (but more than nothing). The best is to put all GPIOs in disconnected input (default state).