iMX7D pad SAI1_TXFS behavior during reset

[carlpii]

While chasing a signal conflict on our custom board, I found that the i.MX7D appears to be driving SAI1_TXFS high whenever POR_B is asserted to the processor.  When I release POR_B, the signal goes back to the expected low state.  I isolated the signal on our board to ensure that no other component could be driving it high and this behavior remains repeatable.  The closest thing I could find in the Reference Manual is in section 6.2.2 (System Reset Controller) where Table 6-6 says that SAI1_TXD is an output of the SRC but there is no mention of SAI1_TXFS.  Is this a documentation error?

There is also no explanation on how the SRC uses SAI1_TXD (or SAI1_TXFS if that is the correct signal).  If the intent is to drive an active high reset from the pin, I believe this deserves highlighting in the Reference Manual as well as in the Hardware Development Guide.

Thank you,
Carl

[Yuri]

@carlpii 
Hello,

   Customers can use table "i.MX 7Dual 19 x 19 mm functional contact assignments"
in the i.MX7D Datasheet to get default pins state (immediately after RESET and
before ROM firmware or software has executed). Columns "Default Function" and
"PD/PU" should be used for it.

  As for the issue with HIGH state: please double check i.MX7 power up sequence:

 VDD_SNVS_IN to be turned on before any other power supply.
 VDD_SOC to be turned on before NVCC_DRAM and NVCC_DRAM_CKE.
 VDD_ARM, VDD_SOC, VDDA_1P8_IN, VDD_LPSR_IN and all I/O power (NVCC_*)
  should be turned on after VDD_SVNS_IN is active.

  Also: 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.

  Note, during power up sequence and short period of stabilization, pin states are not
defined.

Regards,
Yuri.

[carlpii]

Hi Yuri,

The default behavior after POR_B is released is as expected.  My concern is with the behavior of SAI1_TXFS while POR_B is asserted low - it appears to be driven high (not pulled high) while POR_B is low.  This behavior is observed any time POR_B is low, not just at initial power-up.  We have a reset switch that can pull POR_B low.  SAI1_TXFS goes high anytime we press the reset switch.  I am confident our power sequence is within spec.

In short:  Section 6.2.2, Table 6-6 says SAI1_TXD is an output of the System Reset Controller but does not describe its behavior.  Should this pad reference be to SAI1_TXFS and is it driven high while POR_B is asserted low?

Thanks,
Carl

[Yuri]

@carlpii 
Hello,

  what i.MX7 pin is used as  SAI1_TXFS ?
Generally only states of pins, mentioned in Datasheet table 
"Fuses and associated pins used for boot", are specified and
guaranteed. 

Regards,
Yuri.

[carlpii]

Hi Yuri,

I am referring specifically to the SAI1_TXFS pad, not to any peripheral unit that might use that pad or to any other pad the SAI1 unit might utilize.  I see that the iomux registers refer to this pad as SAI1_TX_SYNC.

As I understand it, the descriptions of pin behavior during boot refer to behavior after the release of POR_B when the ROM code is being executed.  I don't see any issues after POR_B is released - the SAI1_TXFS pad is low as expected (ie, it defaults to GPIO mode with a 100K pulldown).  We boot from either USDHC1 or USDHC3, neither of which uses the SAI1_TXFS pad.

I strongly suspect the pad behavior we see on SAI1_TXFS is from the System Reset Controller while POR_B is active. Table 6-6 says that the SRC uses SAI1_RXFS and SAI1_RXC as inputs plus SAI1_TXD as an output but contains no additional details on their use. Additionally, the reference manual revision history (A.1.32) notes that the IOMUXC chapter updated the MUX_CTL_PAD_SAI1_TX_SYNC register which is the pad that is causing us issues. I have since found a copy of the Rev 0.1 release of the reference manual and the revision was to remove Mux Mode 7 from the SAI1_TX_SYNC pad description, specifically:

111  ALT7_SRC_INT_BOOT — Select mux mode: ALT7 mux port: INT_BOOT of instance: SRC

I have a few design changes to make to our board before production so I believe it best to change our use of this pad in the redesign.  I would still like to understand the root cause of the pad behavior.

Thank you,

-Carl 

[Yuri]

@carlpii 
Hello,

  The signals SAI1_RXFS, SAI1_RXC, and  SAI1_TXD, which are used by the SRC
are internal signals, that are not intended for customers. Therefore there are no details 
provided about them.

Regards,
Yuri.