Can't power up RT1020 and RT1050 if the two are connected

[jesse_holwerda]

Hello,

I am trying to have an RT1020 and RT1050 communicate with each other via UART. Specifically, LPUART8 is used on the RT1020 and LPUART3 is used on the RT1050. Both boards are being powered by USB connectors.

If the connections between the two boards are added after both have been powered up, everything works fine. However, if the two board are connected and then powered up, only the first one that was powered will function correctly. The other board goes into maintenance mode and will not run its program.

Any ideas what would cause this?

Thank you,

Jesse

[art · Accepted solution]

The Data Sheet document for both i.MX RT1020 and i.MX RT1050 processors definitely says the following.

"All I/O pins should not be externally driven while the I/O power supply for the pin (NVCC_xxx) is OFF. This can cause internal latch-up and malfunctions due to reverse current flows".

This is definitely the root cause of the issue in your case, since when two processors are connected together and you power up one of them, the I/O signals of the second one become externally driven, whereas the corresponding NVCC voltage is not applied yet. So, use some voltage translator/splitter circuits in board interconnection.

Have a great day,
Artur

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[TomE]

That doesn't work as you're violating both specific conditions in the Data Sheet and some basic "laws of hardware design".

The limit on the voltage on any I/O pin on the CPU is from -0.3V to "OVDD+0.3". By feeding the powered Transmit Data pin into the input on an unpowered board, you're violating that specification. "Not starting up" is a valid response to that violation.

In practice there are "protection diodes" between the input pins and the supplies. And so you're actually trying to power the unpowered CPU through that pin.

That's what transceiver chips are for. They are specifically designed to handle the "signals coming in when unpowered" case.

You're working with prototype boards, so you can bend the rules a bit here. I would suggest putting resistors in series with the data signals to limit the current that is trying to power the other board. If you program the input pins to have the pullups, pulldowns and keepers disabled then you should be able to use high value resistors like 10k or 100k. You're looking for a value that doesn't "lift" the power supply on the board. You may need to add resistors to those power supplies to make sure they stay down, as they may be effectively "floating" with an unpowered chip.

Some devices also specify "injection current limits", which is the maximum current that those protection diodes can take. This is for use in cost-constrained circuits. For instance, in a car there might be a small computer monitoring the brake or parking light switch. That's a 12V level. Rather than divide that down to a 0-3.3V range it can simply be connected through a 100k resistor. These chips don't specify an "injection current" (at least by that name), and even if they did it only applies when powered properly and also comes with the warning to check the design to ensure the "injection current" can't pull the power supply voltages up. Like yours is doing.

And make sure you have a solid ground between those boards. Don't rely on the USB cables or you might get caught out badly if you connect the boards to anything else. Like a Laptop. Some of those have power supplies that float at half the mains voltage, so it is easy to get 50V (USA) or 110V (Europe) trying to get from the laptop to a ground via data pins.

Tom

[jeremyzhou]

Hi Jesse Holwerda,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
I was wondering if you can describe the testing you did, for instance, Eva board,  hardware connection, demo, etc.
Because I'd like to replicate this issue on my site, it will help me to figure the phenomenon out.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[jesse_holwerda]

Hello jeremyzhou,

I'm using the RT1050 and RT1020 evaluation kits. Both boards are powered using the debug USB and both are connected to the same computer. The boards are connected to each other in the following way

RT1020 Pin	RT1050 Pin
J19[9]	J22[2]
J19[10]	J22[1]
J19[7]	J24[7]

Both boards were loaded with programs to test sending messages between the boards. However, I have also noticed this issue even if the RT1020 board is loaded with a different program that does not use those pins at all.

Thank you for your time,

Jesse

[jeremyzhou]

Hi Jesse Holwerda,

Thanks for your reply.
Whether this fail startup issue only happens in the i.MX RT 1020 or not, please clarify it.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[cws]

Note, I work with Jesse. One clarification, in our experience the problem will appear with any example/sample program loaded on the 1020 and 1050 EVK boards. Also, the pin connections listed in Jesse's email are ground, RX and TX for UART8 on the 1020 and UART3 on the 1050 EVK boards.

[carstengroen]

Curt,

I see the same problem on my own RT1062 board. If a USB-TTL serial port is connected to the TP1/TP2 below, the 3.3V rail climbs up to around 1.5V. When connecting power (USB) to the CPU, it will not start until cap C3 below (PSWITCH delay) is shorted briefly. If I only connect the TX pin (TP1) it works, the rail climbs only "a little", if I connect both RX and TX it blocks when power is applied. Guess this is the same story as you see...