i.MX8 Mini GPIO Behavior During Reset

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX8 Mini GPIO Behavior During Reset

1,555 Views
gkilmer
Contributor I

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

0 Kudos
6 Replies

1,441 Views
mobrien
Contributor II

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.

0 Kudos

1,441 Views
igorpadykov
NXP TechSupport
NXP TechSupport

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

0 Kudos

1,441 Views
mobrien
Contributor II

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?

0 Kudos

1,441 Views
igorpadykov
NXP TechSupport
NXP TechSupport

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

0 Kudos

1,441 Views
igorpadykov
NXP TechSupport
NXP TechSupport

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!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

48 Views
Earthshine
Contributor II

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.

0 Kudos