switching pinmux configurations from SAI3 to GPIO pins

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:


GPIO3_IO16 Configuration for Cortex-M Core

Based on the available documentation, there are specific considerations when working with GPIO3_IO16 on Toradex modules with Cortex-M cores.

Known Issue with GPIO3_IO16

There is a documented issue with GPIO3_IO16 on Verdin iMX8M Plus when using it from the Cortex-M core (1). The pin may appear to always read “low” even when voltage is applied, which suggests configuration conflicts in the device tree.

Root Cause Analysis

The issue stems from pin configuration conflicts in the device tree files (1). Specifically:

  • GPIO3_IO16 (SODIMM_64) can be used for I2C3, USDHC3, or NAND functions
  • The pinctrl_flexspi0 node in imx8mp-verdin.dtsi configures this pin for peripheral functions
  • Even when I2C3 is disabled, the pinctrl configuration may still interfere with GPIO functionality

Device Tree Configuration

The current configuration in the device tree shows (1):

&iomuxc {
	pinctrl_flexspi0: flexspi0grp {
		fsl,pins =
			<MX8MP_IOMUXC_NAND_ALE__FLEXSPI_A_SCLK		0x1c2>,	/* SODIMM 52 */
			<MX8MP_IOMUXC_NAND_CE0_B__FLEXSPI_A_SS0_B	0x82>,	/* SODIMM 54 */
			<MX8MP_IOMUXC_NAND_DQS__FLEXSPI_A_DQS		0x82>,	/* SODIMM 66 */
			<MX8MP_IOMUXC_NAND_DATA00__FLEXSPI_A_DATA00	0x82>,	/* SODIMM 56 */
			<MX8MP_IOMUXC_NAND_DATA01__FLEXSPI_A_DATA01	0x82>,	/* SODIMM 58 */
			<MX8MP_IOMUXC_NAND_DATA02__FLEXSPI_A_DATA02	0x82>,	/* SODIMM 60 */
			<MX8MP_IOMUXC_NAND_DATA03__FLEXSPI_A_DATA03	0x82>,	/* SODIMM 62 */
			<MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16		0x82>;	/* SODIMM 64 */
	};
}

(1)

Workaround Solution

The documentation indicates that manual configuration within the Cortex-M program can work, but timing is critical (1):

  1. Early Configuration: If you configure GPIO3_IO16 at the very beginning of your Cortex-M program (started by u-boot), it works
  2. Late Configuration: If you configure it after Torizon OS has booted, the configuration is not overwritten

U-Boot Configuration Issue

There appears to be a mismatch between u-boot and Linux device tree configurations (1). The u-boot configuration may incorrectly set up the pin, which gets corrected later in the boot process.

Recommended Approach

For your Zephyr application on the M core:

  1. Configure the pin early in your Zephyr application initialization
  2. Ensure proper timing - configure after u-boot but before the full Linux boot process interferes
  3. Monitor the boot sequence to identify the optimal configuration window

Alternative Considerations

If GPIO3_IO16 continues to present issues, consider using other available GPIO pins that don’t have the same peripheral function conflicts documented in the device tree.

Note: The specific behavior may vary depending on your exact module version and software configuration. The timing-sensitive nature of this configuration suggests it’s related to the boot sequence and resource ownership between the A and M cores.

Best regards, Toradex AI Assistant.