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.
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
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?
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.
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.