How do I prevent excessive current draw on MX6UL_PAD_UART5_TX_DATA__ECSPI2_MOSI

[JohnKlug]

We are using the i.MX6ULL processor.

We are using UART5_RX_DATA line for ECSPI2_MISO.

Problem

We have done a thermal camera measurement, and then voltage probing, indicating there is a voltage contention between the processor’s MI and the SPI device’s SO pins, namely, they are both driving as outputs.  The pin that is the problem is MX6UL_PAD_UART5_RX_DATA__ECSPI2_MISO.

Before the driver is loaded, the UART5_RX_DATA pin is GPIO1_IO31 and an input as expected. However as soon as we load the spi-imx driver, the voltage on the input pin goes from 3.3V to 2.58V indicating an excess current draw and contention between the two pins. It is expected that the driver would maintain the pin as an input when it is loaded.

Later on when a daemon loads that uses the SPI bus, the contention goes away, thermals look normal, and the bus operates normally.

We do not always run the daemon that uses this SPI bus, but besides that, there should be zero times where two outputs are fighting each other.

Sequence of events

1. After boot of Linux, spi-imx not yet loaded

   Voltage of UART5_RX_DATA pad	3.253V
   Value of SW_MUX_CTL_PAD_UART5_RX_DATA (0x20e00c0)	0x5

2.  After modprobe spi-imx
   

   Voltage of UART5_RX_DATA pad	2.581V
   Value of SW_MUX_CTL_PAD_UART5_RX_DATA (0x20e00c0)	0x8

   We have NVCC_UART set to 3.3V.

Output Drive Relationship to Voltage

As the output drive strength is strengthened, the voltage measured runs lower. As the output drive strength is weakened, the output voltage is raised. If the output drive strength is set to 000, the issue goes away and the voltage hits 3.3V, which is what we expected.

Source Code Version for spi-imx.c driver

 We are using the i.MX6ULL with kernel 5.4-2.1.x-imx from https://github.com/Freescale/linux-fslc.git.

 The last change log to spi-imx.c was:

commit 0a8472f057642c67b84985fec3c65b7ac521ebd8

Merge: 62f022d6ecd0 a998faa9c4ce

Author: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>

Date:   Mon Aug 16 11:14:39 2021 +0000

    Merge tag 'v5.4.140' into 5.4-2.1.x-imx

    This is the 5.4.140 stable release

    Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>

[JohnKlug]

I should make it clear that this problem goes away by disabling the output driver in pinctrl. But the example device tree entry does not do that. So why does the driver decide to make the MISO pin an output on initial load? We do not specify in the device tree that it is a SPI slave, so the pin should not be driven.

[JorgeCas]

Hello,

If you disable the output driver in pinctrl, are you able to use it?

I suggest you follow device tree example, that reduction in voltage level is abnormal. Could you please share your connection?

Best regards.

[JohnKlug]

Everything has always worked (with or without disabling the output), but we discovered after thermal analysis that the MISO pin was being brought to a lower than expected voltage from the time that our driver loaded until the time that our application started (which could be never in our design, theoretically). Before our driver (spi-imx) loads, the MISO pin is a GPIO input, and in that case we measure the 3.2 volts as expected.

We have a one device SPI bus. The output of the slave requires a level shifter that is always on.

The level shifter we are using is 74LVC2T45. MISO output is pin 2. Pin 1 is connected to 3.3V. Pin 4 is connected to ground. Normally we are seeing a high voltage on pin 2 when our slave device is idle. Note that chip select will not effect this voltage, since there is a pull-up on the input to the 74LVC2T45.

MISO is connected to G13 (UART5_RX_DATA) of MCIMX6Y1CVM05. This is tri-stated until the driver is loaded in Linux, at which point this pin becomes output low, which is not desirable.

In device tree we have not selected slave mode. The loading issue goes away when we use iomuxc to disable the output of UART5_RX_DATA.

The issue also goes away when we load our application and it starts talking to the SPI bus.

Given our experience, the NXP device tree example for MISO when the SOC is a master should be disabling the output driver of the MISO pin, instead of enabling it.

[JohnKlug · Accepted solution]

The MISO pin will always be an input when using the SPI interface as a master. The simplest solution is to disable the output for the MISO pin in iomuxc. Then you will not get the MISO pin driven low when the MISO pin is not in use after the SPI Linux driver is loaded.

[JohnKlug]

And I realize now the title should be:
How do I prevent excessive current draw on
MX6UL_PAD_UART5_RX_DATA__ECSPI2_MISO

I got the pins mixed up.