i.MX6DL - Boot behavior depends on state of USB_OTG_ID signal

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

i.MX6DL - Boot behavior depends on state of USB_OTG_ID signal

跳至解决方案
1,295 次查看
christian_neuwi
Contributor III

Hi,

we're building our own hardware based on an i.MX6DL using an eMMC as primary boot device. The BOOT_MODE[1:0] pins are pulled low, i.e. 00b “Boot From Fuses”.

When such a board is in a 'virgin' state (i.e. no firmware installed and no fuses blown), the board behaves as expected as it will always enter "Serial Downloader" mode.

However, things change when a valid bootloader image is installed in eMMC. From that point onwards, "Serial Downloader" mode is entered only when the USB_OTG_ID signal is LOW. Otherwise the installed bootloader image is executed.

That happens even though we haven't programmed any fuses (meaning that also BT_FUSE_SEL = 0), but the iMX6DL reference manual clearly states that this shouldn't happen.

From chapter 8.2.3:

If set to Boot From Fuses, the boot flow is controlled by the BT_FUSE_SEL eFUSE
value. If BT_FUSE_SEL = 0, indicating that the boot device (for example, Flash, SD/
MMC) has not yet been programmed, the boot flow jumps directly to the Serial
Downloader.

What I'm looking for here is a confirmation from NXP that what we're seeing on our boards is actually the intended behavior of the i.MX6DL and the documentation is wrong or incomplete. Ideally, I'm looking for a reference to a different section in the reference manual (or some other document) that documents this behavior and - ideally - explains it.

We don't want to risk breaking our board production process at some point in the future should this behavior change w/o notice.

标签 (1)
0 项奖励
1 解答
969 次查看
igorpadykov
NXP Employee
NXP Employee

Chris, you are right this may be caused by GPIO_1 (ALT6) working as
SD1_CD (could be also USB_OTG_ID) as described in Table 4-2
Muxing Options, Table 8-18. SD/MMC IOMUX Pin Configuration
i.MX6SDL RM
http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6SDLRM.pdf

Best regards
igor

在原帖中查看解决方案

8 回复数
970 次查看
igorpadykov
NXP Employee
NXP Employee

Chris, you are right this may be caused by GPIO_1 (ALT6) working as
SD1_CD (could be also USB_OTG_ID) as described in Table 4-2
Muxing Options, Table 8-18. SD/MMC IOMUX Pin Configuration
i.MX6SDL RM
http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6SDLRM.pdf

Best regards
igor

969 次查看
christian_neuwi
Contributor III

Thanks, Igor.

0 项奖励
969 次查看
igorpadykov
NXP Employee
NXP Employee

Hi Christian

behaviour may be caused by manufacture mode (enabled by default) ,

described in sect.8.11 SD/MMC Manufacture Mode i.MX6SDL Reference Manual:
boot will go to SD/MMC manufacture mode before serial download mode.
http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6SDLRM.pdf

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

0 项奖励
969 次查看
christian_neuwi
Contributor III

Thanks for your response, Igor.

I also thought about SD/MMC manufacture mode, but why does the behavior depend on the state of the USB_OTG_ID signal?

Regards,

Chris.

0 项奖励
969 次查看
igorpadykov
NXP Employee
NXP Employee

Hi Chris

probably your board bootloader uses this pin or it is

somewhere connected to other signals, which could affect behaviour.

ROM does not use it.

Best regards
igor

0 项奖励
969 次查看
dougplymale
Contributor I

Hi igor,

From below, the pad of SD1_CD and SD2_CD are used to detect the card.  SD2_CD is also the USB_OTG_ID pin.  Could it be that we are really seeing the ROM check for the SD2_ID pin?

Thanks,

Doug

pastedImage_1.png

0 项奖励
970 次查看
christian_neuwi
Contributor III

Igor,

Doug probably meant to say that SD1_CD_B and USB_OTG_ID share pin GPIO_01. Pin GPIO_01 also seems to be the only option for either of these functions. As such, it seems to be obvious that the Boot ROM's check for SD1_CD causes this behavior.

Can you confirm that?

Regards,

Chris.

0 项奖励
970 次查看
christian_neuwi
Contributor III

Sorry, USB_OTG_ID can also use a different pad (i.e. ENET_RX_ER), but SD1_CD_B can't. USB_OTG_ID is connected to GPIO_01 on our hardware, though. Just to clarify that.

0 项奖励