GPIO_EMC_39

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

GPIO_EMC_39

1,871件の閲覧回数
sapirbuz
Contributor IV

Hello,

We are using the MIMXRT1051CVL5B in our design.

We are encountering an issue with the B7 pin (GPIO_EMC_39).

We have configured this signal as an input, but when we press the POR button, this pin is driving our external circuit low (we have connected a '1' push-pull configuration to that pin).

Could you please assist us in understanding why this issue is occurring and how we can prevent the MCU from driving it low?

0 件の賞賛
12 返答(返信)

1,832件の閲覧回数
EdwinHz
NXP TechSupport
NXP TechSupport

Hi @sapirbuz,

As mentioned on the RM, on section "11.6.164 SW_PAD_CTL_PAD_GPIO_EMC_39 SW PAD Control Register (IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_39)" bit field "Pull Up / Down Config. Field" is initialized to a "00 PUS_0_100K_Ohm_Pull_Down — 100K Ohm Pull Down" after reset. This is why you are seeing the pin low after a POR.

BR,
Edwin.

 

0 件の賞賛

1,792件の閲覧回数
sapirbuz
Contributor IV

Hi,

IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_41 is defined the same as IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_39, but it isn't driven low while POR.

How can we prevent IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_39 from driving our signal to low after POR?

0 件の賞賛

1,780件の閲覧回数
EdwinHz
NXP TechSupport
NXP TechSupport

Hi @sapirbuz,

Are you currently using the Device Configuration Data (DCD) to set up GPIO_EMC_39? i.e.:

 /* #1.90, command: write_value, address: IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_39, value: 0x110F9, size: 4 */
0x40, 0x1F, 0x82, 0xA0, 0x00, 0x01, 0x10, 0xF9,

BR,
Edwin.

0 件の賞賛

1,681件の閲覧回数
sapirbuz
Contributor IV

yes, we are using that CFG

0 件の賞賛

1,638件の閲覧回数
EdwinHz
NXP TechSupport
NXP TechSupport

Hi @sapirbuz,

This is most likely why this specific pin is being changed upon boot. If you don't use this pin to operate an external memory upon boot, then you should be able to remove it, and the pin will not be configured upon boot.

BR,
Edwin.

0 件の賞賛

1,576件の閲覧回数
sapirbuz
Contributor IV

Hi,

 

we removed the following:

    /* #1.90, command: write_value, address: IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_39, value: 0x110F9, size: 4 */
    0x40, 0x1F, 0x82, 0xA0, 0x00, 0x01, 0x10, 0xF9,

 

and the issue wasn't solved

0 件の賞賛

1,450件の閲覧回数
sapirbuz
Contributor IV

Kindly reminder

0 件の賞賛

1,370件の閲覧回数
EdwinHz
NXP TechSupport
NXP TechSupport

Hi @sapirbuz,

Could you please share the external circuit that you are connecting to the pad? Perhaps the issue lies in the hardware configuration of the pin, rather than the software configuration.

BR,
Edwin.

0 件の賞賛

1,314件の閲覧回数
sapirbuz
Contributor IV

hi,

10k pull up to 3.3V rail, that all

0 件の賞賛

1,251件の閲覧回数
EdwinHz
NXP TechSupport
NXP TechSupport

Hi @sapirbuz,

This issue is most likely caused by conflicts of the DQS functionality of this pad. Could you please share if you are using SEMC functionality to handle an external memory? What type of memory would that be? Also, please check the GPIO/fuse BOOT_CFG [10] (depending on if there is GPIO override or not). Is the "DQS pin pad enablement" on 1 or 0?

0 件の賞賛

1,158件の閲覧回数
sapirbuz
Contributor IV

Hi,

SEMC is used, and the external memory is NOR secondary, as in Picture 1.

BOOT_CFG[10] is configured as input GPIO, PU and keeper are defined as no init.

the DQS pins were left unconnected by HW.

At the beginning, DQS pins were enabled, but the MCU couldn't read the data from the boot EEPROM; so we disabled those pins.

Picture 1:

sapirbuz_0-1695819487786.png

 

0 件の賞賛

1,074件の閲覧回数
EdwinHz
NXP TechSupport
NXP TechSupport

Hi @sapirbuz,

I am still looking into this issue. Could you please double check that the BOOT_CFG[10] fuse is still on 0 (unburned)?

EdwinHz_2-1696631743965.png

It could be an issue that, during booting, the fuse selection of this pin is affecting its functionality, so we need to make sure the DQS fuse is not enabled on fuses for this pad.

0 件の賞賛