UART0 TX pin sometimes pulled low after suspending uart0 and putting MCU into System OFF

[Mike Austin (LPI)]

I've got a product on the market that uses an nRF52832 on a custom board. It's been built with NCS V2.6.1

It spends most of its time in System OFF, and gets woken up by activity on one of several different GPIO.

Just before I put the MCU into System OFF, I suspend the UART:

err = pm_device_action_run(uart0_dev, PM_DEVICE_ACTION_SUSPEND); // Suspend pwm0
k_msleep(5);
sys_poweroff();

However, I've had some issues with power drain on some units, and on further investigation it appears that in some (seemingly random) cases, when the device goes into System OFF, the TX pin gets pulled low. This results in significant current draw during the off period (the TX pin drives an IR LED, so pulling it low draws current through the LED)

I have my UART pins set up as follows:

&uart0 {
status = "okay";
current-speed = <9600>;
compatible = "nordic,nrf-uarte";
pinctrl-0 = <&uart0_fem_default>;
pinctrl-1 = <&uart0_fem_sleep>;
pinctrl-names = "default", "sleep";
};

pinctrl {

uart0_fem_default: uart0_default {
group1 {
psels = <NRF_PSEL(UART_TX, 0, 6)>,
<NRF_PSEL(UART_RX, 0, 8)>;
};
};

uart0_fem_sleep: uart0_sleep {
group1 {
psels = <NRF_PSEL(UART_TX, 0, 6)>,
<NRF_PSEL(UART_RX, 0, 8)>;
low-power-enable;
};
};

I was of the understanding that "low-power-enable" then sets the TX and RX pins as input, high-Z, so that they are effectively floating.

What I want to understand then, is why is my TX pin getting pulled low? It's not happening consistently - seems pseudo random to be honest.

i know I can add some code to reconfigure the TX pin as a GPIO and then pull it high prior to going into System OFF, but I want to understand why the "low-power-enable" isn't doing what it's supppsed to do and actually allow the pin to float?

Can anyone assist?

Regards,

Mike

[Ressa]

Hi Mike, 

Could you provide the schematic of the design or at least UART pins connections, and how they are connected to the LEDs ? Also could you provide the source code here? I would like to see if it is reproducible here.  Do you know exactly how many devices having this issue out of how many samples? And also the amount of current it is drawing vs normal situation ? 

[Mike Austin (LPI)]

Hi Ressa,

I managed to solve my problem.  It was pretty simple in the end.

Stupidly, I had a printk() statement that I called just before putting the MCU into System OFF.  I understand now that the firmware will return from that printk() statement the moment the final character has been sent for TX-ing, so the MCU may be in the middle of transmitting that last character still, when the sys_poweroff() call is made.

Once the sys_poweroff() call is made, the current state of all GPIO is "frozen" during the System OFF period, so if the UART had TX low at that point, that is the state that will latched for the TX pin during System OFF.

And because its effectively a race condition, the likelihood that TX will be either low or high when the MCU enters System OFF will be somewhat random, which is essentially what I was seeing.

I have removed that printk() statement, and now reconfigure the TX pin as a GPIO, set it high, then call sys_poweroff().

That ensures the TX pin behaviour is as I would want it to be

Regards,

Mike