IMX6UL strange bootmode behaviour

[tamasholcsik]

Hello everyone,

We've made a custom board, based on the IMX6UL EVK-14x14, and ran into a strange internal bootloader behavior (from boot_mode pins).

Background:

The board otherwise works fine, memory test ran without problem, everything boots, runs great.

The important changes we've made:
CPU powered from 3V3, the DDR and Core voltage runs from a single 1.35V 700mA stepdown converter. (It's a small board, no need for any fancy power management)
VDD_SNVS_IN are connected to the 3v3 rail directly.
32KHz oscillator's RTC_XTALI pin is connected to GND as the reference manual says. We have an external RTC because of the high current consumption of the IMX6UL's internal RTC.
On the POR_B the board has a MCP130T-2.7 reset chip with 350ms delay
NAND FLASH for storage
(CPU is: MCIMX6G2CVM05AA)

The issue:

When we select BOOT_MODE[1:0]='00' the board is enumerated on USB. This is OK, because it's a blank CPU, it's supposed to do this.
We can download an image to RAM, boot it from there, write/read the NAND FLASH, upload the image to NAND etc, so everything seems to be okay.

BUT, when we select BOOT_MODE[1:0]='01' (serial download) the device doesn't get enumerated, We cant't figure out why....
UART1 and UART2's RXD pulled up with 10k for precaution, and not connected now elsewhere. We tried disabling the UART bootloader from the eFuse, no difference.

The whole board's current consumption is 130mA when "00" is the boot mode, but only 70mA if we select the "01" for serial download. Looks like if it doesn't want to start or something.

Before We've made a prototype  (2pcs, "old boards" ), they work fine. 1 board got the eFuses written, 1 board's CPU is blank.
On one of the old boards we can select '00' and '01' mode, and the USB gets enumerated (BOOT_CFG resistors got desoldered),
 
On the new boards (4 pcs, all of them got this issue), we deleted the BOOT_CFG resistors, because we have the right settings for the eFUSE (but now they are not programmed yet).

We tried all of the new modifications on the old board (single 1.35V for RAM and CPU, SNVS to 3.3V, XTALI to GND). On the old board's we can select '00' and '01' mode, and works.  

Only on the new board we can not start the USB bootloader on '01' setting.   

Both boards (new vs old) are using REV1.1 CPU-s (1N52P) but of course the batch number is different (CTAW1651 /CTAG1626)

We are concerned, if We program the fuse bits (so it would boot from NAND), the board can't go in to USB download next time if needed, still developing the firmware.
So we haven't made this step for precaution.

(Or is it possible to short some pin on the NAND and get a fallback mode to USB bootloader?)

Anyone encountered this problem?

Thanks,
Tamas

[igorpadykov · Accepted solution]

Hi Tamas

as BOOT_CFG resistors are deleted, this may be caused by BOOT_CFG4[7] signal

please check i.MX6UL Reference Manual (rev.1  4/2016) Table 8-2. Boot eFUSE Descriptions

http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6ULRM.pdf

one can attach jtag debugger and check SRC_SBMR1 register, described on

sect.49.7.2 SRC Boot Mode Register 1 (SRC_SBMR1)

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

[tamasholcsik]

Thanks for the reply!

I didn't mentioned, that we use the LCD lines for different alternate functions, CAN, I2C, GPIOs, etc...
And we use this BOOTCFG[4]7 (LCD_DATA23) for a reset line to the Ethernet PHY. (On the new board of course, this is different from the old ones)
The PHY has an internal pull up on this pin. So, infinite loop by the reference manual.

Ooops...You were right!

I've pulled down this line with a 10k to GND, and it now gets enumerated on USB, with BootMode[1:0]='01', like it should. So it's fixed for now.

The only thing I can't see, is why does this occur. The reference manual doesn't state this clearly, that the BOOT_CFG pins are read when in this boot mode ('01'). (Like on Figure 8-2). So I overlooked on this thing.

It would have been fixed if we program the fuses.
(Yesterday, I tried shorting DATA0 on the NAND, on one of the old board with programmed eFuses to boot from NAND, and it's got enumerated. So it can fall back to USB bootloader. Good to know.)

Thanks again!

Tamas