Interrupt Input boots up as Output

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Interrupt Input boots up as Output

1,508 Views
steffendoster
Contributor IV

Hello,

I have a very strange behavior on an Interrupt Input. The whole story:

I'm running Linux on an i.MX6 Solo Processor on a custom Board. It is connected to a ti-WLAN module WL1837 via SD-Interface.

To operate this module it is necessary to have an interrupt input comming from the module.

I already implemented this on another custom board and it works perfectly. The difference between the two boards are:

- The SD-Interfaces are different (SD2 and SD4)

- The Interrupt Pin is different

- The board I now want to bring up needs a levelshifter because WL1837 Interface is 1.8V and the IOs of the i.MX6 on this board needs to be operated on 3.3V.

I derived the Devicetree-Part for WLAN of the board from the successful implementation of the other board.

But it doesn't work. On bootup there are plenty error messages that the Kernel can't get the module to work.

(on Monday I will provide detailed Error-Messages and Devicetree codes)

After long research I found the failure:
The Interrupt pin on i.MX6 seems to be configured as Output Pin with '0' assigned.

When I switch it to Input (by the old fashioned way: echo gpio-number to export and setting direction in this gpio) I can bring up the WLAN-module perfectly. Then everything works like it has to.

The problematic Pin is NANDF_CS3 configured as GPIO6_IO16 thus it is linux gpio 176.

Why does Linux configure this Interrupt-Input as Output? How can this be possible? I checked and checked again my IO-Muxing and the other configurations in Devicetree but didn't find an error yet. Can you give me any hint or help?

On Monday I will provide more information like devicetree and error messages. Just say what you need to help me.

Thanks

I have now attached parts of my devicetree. My DT is seperated in several files sorted by bus/interfaces or functions.

The base.dtsi represents my base system with thins that nearly never change and where everything else is attached to.

I think iomux.dtsi and usdhc.dtsi is self explaining.

I also forgot to mention:

I'm using Linux-Kernel 4.19.127 and Debian 9 on this device.

The relevant code-snippet (as I think):

IOMUXING:
pinctrl_hog: hoggrp {
fsl,pins = <
MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b0     /* LED CAN Run */
MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0     /* LED CAN Error */
MX6QDL_PAD_NANDF_D3__GPIO2_IO03 0x1b0b0     /* 5V 12V Poweroff */
MX6QDL_PAD_NANDF_D4__GPIO2_IO04 0x1b0b0     /* Dig Out 0 */
MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x1b0b0     /* Dig Out 1 */
MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x1b0b0     /* Dig Out 2 */
MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x1b0b0   /* Dig In 0 */
MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x1b0b0   /* Dig In 1 */
MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x1b0b0   /* Dig In 2 */
MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x1b0b0   /* WLAN Interrupt */
MX6QDL_PAD_GPIO_3__GPIO1_IO03 0x1b0b0            /* USB H1 PWR En */
MX6QDL_PAD_EIM_D29__GPIO3_IO29 0x1b0b0          /* USB OTG PWR En */
>;
};

pinctrl_wlan_vmmc: wlan_vmmcgrp {
fsl,pins = <
MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x13059 /* WLAN Enable */
>;
};

pinctrl_usdhc4: usdhc4grp {
fsl,pins = <
MX6QDL_PAD_SD4_CMD__SD4_CMD 0x17059
MX6QDL_PAD_SD4_CLK__SD4_CLK 0x10059
MX6QDL_PAD_SD4_DAT0__SD4_DATA0 0x17059
MX6QDL_PAD_SD4_DAT1__SD4_DATA1 0x17059
MX6QDL_PAD_SD4_DAT2__SD4_DATA2 0x17059
MX6QDL_PAD_SD4_DAT3__SD4_DATA3 0x17059
>;
};

WLAN Enable Regulator:

reg_wlan_vmmc: regulator@5 {
compatible = "regulator-fixed";
reg = <5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_wlan_vmmc>;
regulator-name = "reg_wlan_vmmc";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
gpio = <&gpio2 7 GPIO_ACTIVE_HIGH>;
startup-delay-us = <70000>;
enable-active-high;
};

The USDHC-Interface the WLAN-Module is attached to:

usdhc4: usdhc@0219c000 {
compatible = "fsl,imx6q-usdhc";
reg = <0x0219c000 0x4000>;
interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_USDHC4>,
<&clks IMX6QDL_CLK_USDHC4>,
<&clks IMX6QDL_CLK_USDHC4>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc4>;
non-removable;
vmmc-supply = <&reg_wlan_vmmc>;
cap-power-off-card;
keep-power-in-suspend;
status = "okay";

#address-cells = <1>;
#size-cells = <0>;
wlcore: wlcore@0 {
compatible = "ti,wl1837";
reg = <0>;
interrupt-parent = <&gpio6>;
interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
};
};

Do you need more informations?

Labels (3)
0 Kudos
7 Replies

1,353 Views
steffendoster
Contributor IV

Hi,

it seems I have found the cause of the problem:

My Bootloader configures this pin as Output with value '0'.

What I don't get is: why is Linux/Devicetree not able to correct this setting?

0 Kudos

1,353 Views
igorpadykov
NXP Employee
NXP Employee

linux dts does not configure (change) gpio direction.

0 Kudos

1,353 Views
igorpadykov
NXP Employee
NXP Employee

Hi Steffen

NANDF_CS3 is configured as GPIO6_IO16 output and used as LCD CABC_EN

signal on i.MX6DL-SDP Sabre schematic :

hannstar_cabc.. lvds1 {gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>;   in   imx6qdl-sabresd.dtsi
https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm/boot/dts/imx6qdl-sabresd.dtsi?h=i...

Design files, including hardware schematics, Gerbers, and OrCAD files for i.MX 6Quad (i.MX 6Dual emu...

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

0 Kudos

1,353 Views
steffendoster
Contributor IV

Hi Igor,

well this could answer my question IF I use SabreSD. But as I mentioned in my original post I use a custom board. And on this board NANDF_CS3 is only wired to the Interrupt output of ti, wl1837 and is configured as GPIO16.

So this does not apply to me, sorry.

Greetings

Steffen

0 Kudos

1,353 Views
igorpadykov
NXP Employee
NXP Employee

Hi Steffen,

 

nxp supports only nxp reference boards and boards which are based on these designs.

For other designs developed and based on third party boards may be recommended

to apply to tech support of vendors of these boards.

Best regards
igor

0 Kudos

1,353 Views
steffendoster
Contributor IV

Hi Igor,

I am the vendor!

Greetings

Steffen

0 Kudos

1,354 Views
igorpadykov
NXP Employee
NXP Employee

Hi Steffen

one can try to debug it, printf or attach jtag debugger and

check IOMUXC_SW_MUX_CTL_PAD_NAND_CS3_B, GPIOx_GDIR registers described in

sect.37.4.156 Pad Mux Register (IOMUXC_SW_MUX_CTL_PAD_NAND_CS3_B),

sect.29.5.2 GPIO direction register (GPIOx_GDIR)

i.MX 6Solo/6DualLite Applications Processor Reference Manual

May be helpful Using Open Source Debugging Tools for Linux on i.MX Processors

Also recommended to reproduce issue on i.MX6DL Sabre SD board with nxp linux :

linux-imx - i.MX Linux kernel 

Best regards
igor

0 Kudos