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,337件の閲覧回数
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 解決策
1,011件の閲覧回数
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 返答(返信)
1,012件の閲覧回数
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

1,011件の閲覧回数
christian_neuwi
Contributor III

Thanks, Igor.

0 件の賞賛
返信
1,011件の閲覧回数
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 件の賞賛
返信
1,011件の閲覧回数
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 件の賞賛
返信
1,011件の閲覧回数
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 件の賞賛
返信
1,011件の閲覧回数
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 件の賞賛
返信
1,012件の閲覧回数
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 件の賞賛
返信
1,012件の閲覧回数
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 件の賞賛
返信