[100221 SW AL] UART device not going low power

RE: [100221 SW AL] UART device not going low power

ovrebekk — Wed, 16 Nov 2022 09:09:52 GMT

Thanks for the update.

So to summarize then, the problem is about putting the UART in a low power state on the nRF9160 side, when the TX pin is reconfigured either as an output or with pull down enabled.

If this is the case it seems like the UARTE interface is not properly disabled when the UART driver goes into a low power state. Are you able to check the state of the ENABLE register in the UARTE peripheral after you have set it to low power?

Could you try to manually set the ENABLE register to 0, and see if it fixes the current consumption issue?
For this fix to work properly, you would have to restore the original value before enabling the driver again.

I will do some testing on my own side, and also have a closer look at the driver implementation, to see what actually happens when the driver enters the low power state.

Best regards
Torbjørn

RE: [100221 SW AL] UART device not going low power

SODAQHW — Tue, 15 Nov 2022 12:43:04 GMT

We are currently using the sdk v1.6.1, so no pinctrl is used.

I tried to configure the pin with the pull down resistor instead of configuring it as output, the reset of the nRF52840 works but the power consumption problem remains.

I see the same power consumption as before putting the UART to low power, ~500uA

RE: [100221 SW AL] UART device not going low power

ovrebekk — Mon, 14 Nov 2022 09:08:39 GMT

Which version of the nRF Connect SDK are you using?

If you have 'low-power-enable' set in the pinctrl configuration then the pins should be configured to input mode once you set the driver in low power mode.

If you then enable the pull down resistor on the pin then this should pull it low, similar to setting it as an output in the low configuration (just with less drive strength).

Would you be able to try this out, and see if it solves the issue?

You would need to disable the pull down before taking the UART driver out of the low power state.

Best regards
Torbjørn

RE: [100221 SW AL] UART device not going low power

SODAQHW — Fri, 11 Nov 2022 14:01:55 GMT

Leaving the TX pin high would not power up the nRF52840 again, but it doesn't let it shut down.

The problem is that since the nRF52840 is configured to be low power and uses just few uA while not beaconing, the current coming from the nRF9160 TX pin is enough for it to not shut down quickly and reliably.

Only a beaconing event in the nRF52840 requires enough power to drain the energy accumulated in the UART lines, resulting in the device shutting down (most likely due to a brownout).

Having the beaconing interval set to 10 seconds we would have to wait more than 10 seconds to be sure that the nRF52840 is completely powered down, and that is not desirable.

You should be able to reproduce the issue using development kits and following my description, i will give you a bit more context on the setup.

- nRF9160 and nRF52840 are connected to each other through UART

- nRF9160 controls the power of the nRF52840 through a GPIO (i will refer to it as nRF5_EN)

Initial situation is:

- nRF9160 has the UART to the nRF52840 enabled, while the nRF52840 is in low power mode (UART disabled)

if in this situation the nRF9160 removes power to nRF52840, driving the nRF5_EN pin LOW. Now is possible to see that the nRF52840 is still running for some time (at least 1/2 seconds in out tests), unless it does something in order to consume the accumulated current (for example beaconing).

Our only way to be sure that the nRF52840 is powered down quick is the sequence of actions i described in the original post, so to configure the TX line on the nRF9160 side to OUTPUT.

I hope i made the situation more clear, please let me know if it's not.

RE: [100221 SW AL] UART device not going low power

ovrebekk — Fri, 11 Nov 2022 13:08:32 GMT

Why would leaving the TX pin high power up the nRF52840 again?

Since this pin would be the RX pin on the nRF52840 side it would seem more intuitive if a low signal would wake it up, since this is typically a sign of UART activity.

I need a bit more time to look into the consequences of overriding the TX pin while the driver is running. There is no good way of reassigning pins dynamically in the nRF Connect SDK unfortunately, and it is quite likely that doing this will have some unintended side effects.

I assume I should be able to reproduce this issue using standard development kits, and by following your description?

Best regards
Torbjørn