IMX6Q SD3 boot problem

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

IMX6Q SD3 boot problem

Jump to solution
1,922 Views
rkim
Contributor II

We have a custom IMX6Q board with 2GB of DDR3.

  

We boot from SD3 (4-bits) with BOOT_CFG[7:0] = 0100 0000; and BOOT_CFG2[7:0]= 0011 0000.  BSP is based on Adeneo WEC7 BSP v1.7 (we have different IOMUX pinouts)- we haven’t made the 1GB-> 2GB ddr3 changes yet.

  

Problem:  Our board doesn’t boot up consistently from SD3 (a micro-high capacity/4GB)- if we reset it (POR_B=0) repeatedly, it may or may not boot up.   The likelihood of failure varies from board-to-board (some rarely fail and other do so ~50% of the time).

When it doesn’t boot, the SD3 clock is 50 MHz and there’s brief activity on the CMD/data lines before it stops.
In this state, we can still run the DDR stress test (USB serial) so the IMX6Q is still functional.  (We’ve run the DDR stress test for hours w/o failing.)

  

When the board boots up , we can connect with JTAG (Lauterbach).  But we can’t connect with JTAG when SD3 fails (USB serial download also won’t work). 

When the board boots and JTAG connects, SRC_SBMR1= 0x 40 00 30 40.

ERR006282 seems N/A because the boot problem is too frequent.  ERR004536 also seems N/A because we’re using SD (512 byte block size).

  

SD3 signal integrity is good and all SD3 traces are < 1 inch long.

POR_B looks fine (get same results with a rise-time < 5ns and with a very slow-rise time like Sabre).

IMX6Q version: MCIMX6Q5EYM10AC

PMIC version: PMPF0100F0AEP

PMIC voltages look good. Note:  we’re using the new –A version (not fully tested since they were samples).

Anyone have any ideas?

Thanks.

Labels (1)
Tags (1)
0 Kudos
1 Solution
1,239 Views
rkim
Contributor II

This project was put on hold for over a year but recently became active again- and this problem was finally resolved.   The local NXP FAEs determined the DDR3 settings (borrowed from Sabre) were marginal for our layout.  With new values in the IVT file, all boards boot reliably now from the SD card (at least at room temperature). 

Note: the BSP DDR3 values (in IVT) are different from NXP's DDR3 stress test.  But neither values were really ideal for our layout.

View solution in original post

0 Kudos
6 Replies
1,239 Views
dmitriyaleksand
Contributor II

Hi Rich,

probably DDR stress test uses USB Recovery mode and that is why it always works. EBOOT initialization is quite different: it has a plugin which is executed at startup, check ivt_init.s file. There you can find low level initialization including DDR memory and clocks. First of all I would recommend to decide whether this problem is related to hardware or software. You can change ivt_init.s so it would access GPIO ports as early as possible (before DDR initialization). Don't forget to add "while(1);" stubs just after accessing debug LED, something like:

loop

     b loop

This will prevent SoC resetting due following incorrect execution.

Regards,

Dmitriy

0 Kudos
1,240 Views
rkim
Contributor II

This project was put on hold for over a year but recently became active again- and this problem was finally resolved.   The local NXP FAEs determined the DDR3 settings (borrowed from Sabre) were marginal for our layout.  With new values in the IVT file, all boards boot reliably now from the SD card (at least at room temperature). 

Note: the BSP DDR3 values (in IVT) are different from NXP's DDR3 stress test.  But neither values were really ideal for our layout.

0 Kudos
1,239 Views
Chris1z
Contributor III

You said likely hood of failure varies from board to board.  Have you taken the SD card from a "Bad" board and put it in a "Good" board to see if the issue follows the SD card?

Have you put something very very early in your bootloader (like where DDR settings get loaded/CDC registers) that toggles an LED or GPIO so you can tell if it got to that point in the code?

You probably do want to get the correct values in for your DDR config soon and run the DDR calibration. 

0 Kudos
1,239 Views
rkim
Contributor II

Thanks for the reply.

Yes, we've moved the SD card from board-to-board but the SD card doesn't matter.

We also modified the BSP by leaving all pins unconfigured except for SD3 and one GPIO that turns on a LED- the LED is turned on first thing.  But we're not reaching that point when it doesn't boot.  It's also possible this isn't a HW problem and something is wrong with the BSP image (SD cards should be fine since this happens with multiple cards).


0 Kudos
1,239 Views
dmitriyaleksand
Contributor II

Hi Kim,

could you clarify how does your system booted? Are you using EBOOT and NK or just NK without EBOOT?

Any debug messages?

Regards,

Dmitriy

0 Kudos
1,239 Views
rkim
Contributor II

Dmitriy,

We're using EBOOT and NK.  When the SD boot fails, we don't get any serial output and our debug board LED (driven by a GPIO) doesn't light up.

At this point, I doubt the problem is related to the SD interface itself or the reset (POR_B).  We also looked into our 24 MHz crystal because the Vybrid link below seems like the same problem (but it turns out the IMX6Q's oscillator does not get reset by POR_B).

https://community.freescale.com/message/351984#351984

One strange thing we found is there's brief activity on I2C3 (only thing on I2C3 is the IMX6Q master and the PMIC slave) without a SD card.  With a SD card, there's no activity on I2C3.  So now we're looking into our PMIC- also, we have the PMPF0100NPEP PMIC, not the newer -A version as stated above.

Thanks,
Rich

0 Kudos