i.MX8 Mini GPIO Behavior During Reset

[gkilmer]

Hi there,

I am working on a project using the i.MX8 Mini and we are running into an issue regarding the GPIO's behavior during reset. It seems as though the GPIO's are being actively driven high by the CPU before POR_B goes high and the CPU comes out of reset. This is a problem for our project because we do not want these GPIO's to trigger components down the line. I have attached a scope picture, SAI1_TXD7.png, and in this picture the blue is VDD_3V3, purple is POR_B and yellow is SAI1_TXD7. As you can see, the SAI1 line goes high before the CPU comes out of reset. We use this signal as a strap option for boot up so I know that the datasheet calls this signal out as an input on reset, see SAI1_TXD7_Datasheet.png. We have a 2K2 Ohm external pull down resistor on this pin so knowing this, it looks as though the CPU is actively driving this pin high during reset. I have attached another picture, GPIO7.png, that shows this behavior on GPIO1_IO07 and is one of the GPIO's that we really do not want to trigger during reset. Finally, I have attached yet another scope shot of GPIO1_IO05 in the picture GPIO5.png. This GPIO stays high for 1.3 seconds before it finally comes down and it seems the CPU finally takes over and makes it a low signal. Both GPIO7 and GPIO5 have 100K Ohm external pull down resistors on our board.

As I mentioned, this behavior is extremely undesired as the GPIO toggling is causing issues down the line on our board. Is this behavior expected on this chip? I could not find anything in the datasheet or reference manual that discussed in detail what to expect of the pins during reset before POR_B goes high.

Thank you and I'd be happy to answer any questions regarding our board to help with this problem,

Grant

[martmanmtx]

we have the same issue on imx8mp where during reset the GPIOs seem to be tight up to 3.3V. this is bad as 1 of the GPIOs is used to trigger hardware power off of the complete system. hence everytime on power on reset the system will be switched off. took the complete schematic from an other system where Atmel SAMA5D3 was used not causing this issues.

Question: can those GPIOs which will later be configured as outputs pulled down by external pulldown to get defined status of the GPIO during reset or will this damage the imx8mp?

Question: what exactly does "undefined behaviour" mean? does this mean it can either be high, or low or something in between?

[mobrien]

We found an issue that was causing part of this problem. A device on our board was back powering the 3.3V rail so it came up early - out of the correct sequence. Once we fixed this the issue of the short glitch on the IO pins was solved. However there is a different issue with GPIO1_IO05. The processor is driving this pin while in reset and does not release it until uboot starts. We have not found a way to keep this pin quiet during boot.

[igorpadykov]

if this happens before full power-up sequence is finished, it can be considered

as normal and unfortunately can not be avoided.

Best regards
igor

[mobrien]

For GPIO1_IO05 (Ball AF12) we are seeing different behavior than the other pins. It is driven high at power on and stays high for ~1.3 seconds. Is there any reason why this pin behaves different from all the other pins?

[igorpadykov]

Hi Michael

in general, until power-up sequence is finished, pins state is not guaranteed.

They may behave differently as controlled by different modules with different

power domains - "Power group" column in Table 64. i.MX 8M Mini 14 x 14 mm functional contact assignments

i.MX 8M Mini Applications Processor Datasheet for Consumer Products

Best regards
igor

[igorpadykov]

Hi Grant

yes such behavior expected. Reason is that before the chip is fully powered-up
and POR_B goes high, internal logic to control the connection gpio's circuits is not initiated.

Background of such behaviour can be found for example in early i.mx AN2537

sect.3.3.3 i.MX Connection Leakage due to Unstable State During Power-Up

https://www.nxp.com/docs/en/application-note/AN2537.pdf 

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

[Earthshine]

Will this also be the case with the i.MX8M Plus - that GPIO's are unpredictable during reset?  We're also seeing similar behavior where GPIOs are going to ~1.5V for up to about 50ms on reset.  This is obnoxious, because it means we need external gate logic to prevent these glitches from activating the various peripheral circuits they're supposed to be (eventually) driving.  Example shown is SAI5_RXFS, which we map to PWM4 once the firmware gets going.