i.MX6 solo boot problem on custom board

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

i.MX6 solo boot problem on custom board

Jump to solution
7,077 Views
krisroh
Contributor I

Hello,

I have some units have boot failure on the custom board. (about 5~7% failure out of 200 units).

I'd like know if anyone else saw the similar problem below.

The custom board has been designed with

- i.MX6 solo (MCIMX6S5DVM10AB)

- PMIC (MMPF0100F0EP)

- MAX8903CETI+ (system power + charging IC)

- DDR3 (4Gbit x 4)

- eMMC (8GByte)

- microSD card

Boot configuration settings are;

BOOT_CFG1[7:0] = 0x60 (eMMC boot)

BOOT_CFG2[7:0] = 0x58 (SD4, 8bit)

BOOT_CFG3[7:0] = 0x00

BOOT_CFG4[7:0] = 0x00

<Good units>

a. Blank eMMC

When I supply 5V to the board, the current consumption stays around 170mA. Nothing happened as there is no code in eMMC.

b. After download the code into eMMC,

The current drain is changed dynamically upto 550mA, and then stabilized at 230mA.

<Failure units>

a. Blank eMMC

When I supply 5V to the board, the current consumption stays around 60mA.

b. After download the code into eMMC (I need some trick to download the code into eMMC),

The current drain stuck at 60mA. Nothing happened.

I checked all clock is running properly, and the power supply from the PMIC is within proper range.

The only way to exit the failure mode is the short pulse on hard-reset signal. (working properly with < 60ms reset , failed agin with > 80ms reset).

*. During design the custom board, I connected a pull-up to EIM_EB3 (BOOT_CFG4[7]) then I saw same symptom. (stuck at 60mA since BOOT_CFG4[7] = 1 enables infinite loop at start of boot ROM). I already isolated this issue.

** I also tried another boot configuration (boot from microSD card), but same result on the failure units.

*** VDD_ARM_CAP (i.MX6 internal LDO output) is not changed on the failure units while it is change to 1.2V on the good units. (waveform attached). Do you know who will change this LDO output? Is it internal BOOT ROM?

**** As you see above, failure mode is not related with custom code. It seems i.MX6 internal Boot ROM is not running properly with unknown reason.

I would appreciate if you'd share your experience how to debug this issue.

Thank you,

Kris

Labels (1)
Tags (1)
0 Kudos
1 Solution
4,428 Views
igorpadykov
NXP Employee
NXP Employee

Hi Kris

if prolonging POR helped,

this means that power supplies (or crystal oscillators frequency)

did not reached normal value when POR released.

Probably there are some capacitors with too big values,

one can recheck/compare with i.MX6 SDP/SDB board schematic.

Best regards

chip

View solution in original post

0 Kudos
16 Replies
4,428 Views
igorpadykov
NXP Employee
NXP Employee

Hi Kris

iROM does not use LDOs.

Please try to update DDR calibration settings with links below

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

https://community.freescale.com/docs/DOC-96412

Also issue may be casued by soldering issues, one can try to resolder

processor.

Just for test it may be useful to boot small examples with SDK (not use OS)

i.MX 6Series Platform SDK : Bare-metal SDK

Best regards

chip

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

0 Kudos
4,428 Views
krisroh
Contributor I

Thank you for timely response, Chipexpert.

<Summary of symptoms>

Good unit - 170mA current drain (Without custom code), Dynamically changed upto 550mA (with custom code)

Failure unit - 60mA current drain (Without Custom code), Stuck at 60mA (with custom code)

1. DDR3 calibration.

We provided DDR3 trace length to Freescale, and get the register settings from freescale.

We already applied the DDR3 calibration.

As far as I know, DDR3 calibration is a part of custom boot loader.

But my test is done without any custom boot loader (No eMMC programmed / No SD card inserted), so DDR3 calibration should not a root cause.

2. Resoldering processor

We already Reflowed/replaced several failed board, but the board is not recovered by reflow/replace the processor.

It should not soldering issues because the failed unit is recovered by short hard-reset (< 60ms).

3. VDD_ARM_CAP (Waveform has been attached on the first post).

VDD_ARM_CAP (i.MX6 internal LDO output) is not changed on the filure units, but it is changed to 1.2V on the good units.

This test is done without any custom boot loader (i.e No eMMC programmed / No SD card inserted).

Does iROM control i.MX6 internal LDO output voltage?

Thank you,

Kris

0 Kudos
4,428 Views
igorpadykov
NXP Employee
NXP Employee

Hi Kris

>Does iROM control i.MX6 internal LDO output voltage?

No. iROM does not use LDOs.

5~7% failure may means that smth wrong in soldered

components. Probably it make sense to run minimal ltib image

and try to boot with lower frequency. Please check i.MX6DQ RM

Chapter 8 System Boot, BT_FREQ (BOOT_CFG3[2]).

This will make system to use less current, there will be less voltage ripples.

Best regards

chip

0 Kudos
4,428 Views
krisroh
Contributor I

Thank you for your comments, Chipexpert.

I don't think that something wrong in soldered components because the same failed units are recovered by applying a short pulse onto the hard-reset signal.

I added 1K pull-up resistor on BT_FREQ (BOOT_CFG3[2]) to boot with lower frequency, but the result is same.

Failed unit shows 60mA current drain, but it drains about 135mA after applying a short pulse onto the hard-reset signal (It was 170mA in higher frequency boot).

So it is confirmed that the failed board is booting with lower frequency correctly, but it still failed.

You mentioned iROM does not use LDOs, then who controls VDD_ARM_CAP output? There is no program running.

I will capture the waveform from the SABRE board after removing SD card next week.

Best regards,

Kris

0 Kudos
4,429 Views
igorpadykov
NXP Employee
NXP Employee

Hi Kris

ROM does not use (read/write) LDOs, they are just in default state.

Sect.50.7.1 Digital Regulator Core Register (PMU_REG_CORE)

IMX6DQRM i.MX 6Dual/6Quad Applications Processor Reference Manual

Do you have 2.2Mom on XTALI ?  i.MX6 SDP schematic SPF-27392 p.3 -

fixing 24MHz slow starting.

Also one can try manually to prolong i.MX6 POR (connected to

MMPF0100 RESETBMCU) - just to test if all power supplies reached

good state before POR release.

Probably reason in board noise, just for test one can touch high impedance

probe of oscilloscope to eMMC and try to boot (this will add some capacitance to

trace).

Best regards

chip

4,429 Views
krisroh
Contributor I

Thank you for your comments, Chipexpert,

1. VDD_ARM_CAP (1-1 & 1-2 waveform attached)

> ROM does not use (read/write) LDOs, they are just in default state.

According to my measurement attached, VDD_ARM_CAP output is not changed in the failure mode but it is changed in the pass mode.

In the pass mode, VDD_ARM_CAP is always steped-up 13msec later after POR_B is released.

You mentioned internal LDOs are in default state, then why it is not changed in the failure mode?

I'd like to know what circuit can cause this problem.

2. 2.2Mohm on 24MHz XTALI (2. schematic attached)

Yes, We have 2.2Mohm pull-down resistor on XTALI. Our schematic has been attached.

3. eMMC signals

Unfortunately I don't have any access point for eMMC interface signals. They are all routed in inner layer.

As I mentioned before, this failure mode (60mA) / pass mode (170mA) is tested without eMMC/SD card. This current consumption is happened by i.MX6 itself.

4. Manually prolong POR_B (4. waveform attached)

I added a 1uF shunt capacitor on POR_B signal to prolong POR_B manually (about 90msec delay), then the failed unit becomes good unit.

What does it mean?

Does freescale agree to add a 1uF shunt capacitor on POR_B signal?

Is there any other possible root cause (i.e. too much bypass cap on i.MX6 side)?

I'll modify 5 more units to confirm if a 1uF shunt cap will fix all failure units.

Regards,

Kris

0 Kudos
4,429 Views
igorpadykov
NXP Employee
NXP Employee

Hi Kris

if prolonging POR helped,

this means that power supplies (or crystal oscillators frequency)

did not reached normal value when POR released.

Probably there are some capacitors with too big values,

one can recheck/compare with i.MX6 SDP/SDB board schematic.

Best regards

chip

0 Kudos
4,429 Views
krisroh
Contributor I

Hi chipexpert,

I modified 4 more units, and all failure units become good units by adding a 1uF shunt capacitor on POR_B.

I compared our schematics with SPF-27516 schematics. All bypass cap value is same except below.

We only have the extra bulk capacitors installed on our board while it is DNP on SABRE board.

VDDSOC_CAP: 22uF (x2)

VDDPU: 22uF

VDD_SNVS_CAP: 22uF

HDMI_VP: 4.7uF

HDMI_VPH: 4.7uF

Is there any specific reason why these bulk caps are DNP on SABRE board?

We also have additional circuit as below.

DC/DC (discrete part for 3G module) output: 22uF (x2)

3G module bypass cap (connected to discrete DC/DC output): 100uF (x5)

I'll remove these bulk capacitors one by one to check if it affects boot up problem.

Thank you,

Kris

0 Kudos
4,429 Views
igorpadykov
NXP Employee
NXP Employee

Hi Kris

yes, values of capacitors on i.MX6 LDO outputs are very critical,

please check latest schematic and install exactly the same values

"MX6_SABRE_SDP_DESIGNFILES "

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=RDIMX6SABREPLAT&fpsp=1&tab=Design_Too...

Best regards

chip

0 Kudos
4,429 Views
krisroh
Contributor I

Hi Chipexpert,

After removing 2 x 22uF on VDDSOC_CAP, 5 failed units become good unit.

But I couldn't find any difference except below from the waveform attached.

- 1. Pass mode without 2 x 22uF: VDDSOC_CAP reaches 1V, then discharged => POR_B released => VDDSOC_CAP jumps to 1.1V => changed to 1.2V

- 2. Fail mode with 2 x 22uF: VDDSOC_CAP reaches 0.8V, then discharged => POR_B released => VDDSOC_CAP jumps to 1.1V => stay on 1.1V

- 3. Pass by a short hard reset with 2 x 22uF: VDDSOC & VDDSOC_CAP discharged => VDDSOC_CAP reaches 0.8V, then discharged => POR_B released => VDDSOC_CAP jumps to 1.1V => changed to 1.2V

Would you please let me know why POR_B is released during VDDSOC_CAP is discharged?

Do we need more time delay on POR_B (i.e adding a 1uF shunt cap on POR_B will delay POR_B about 90msec)?

According to the test result, there are 2 possible solutions as below.

a. DNP 2 x 22uF on VDDSOC_CAP same as Freescale reference design.

I'm not sure if POR_B timing is desired as attached waveform.

b. Adding a 1uF shunt cap on POR_B.

Do you think if there is any side effect with this capacitor?

Any comments on solution a & b would be appreciated.

Thank you for your help,

Kris

0 Kudos
4,429 Views
igorpadykov
NXP Employee
NXP Employee

Hi Kris

prefered solution is follow

i.MX6 Sabre SDP/SDB design - use the same number of 22uF

capacitors. This is verified solution. This is also mentioned in

i.MX6 System Development User’s Guide (rev.1, 6/2013)

http://cache.freescale.com/files/32bit/doc/user_guide/IMX6DQ6SDLHDG.pdf

Best regards

chip

0 Kudos
4,429 Views
krisroh
Contributor I

Hi Chipexpert,

I modified 10 failure units to DNP the bulk caps on VDDSOC_CAP, VDDPU and VDD_SNVS_CAP.

2 units are still failed after modification.

In hardware development guide, 10uF capacitor is recommended for the power rail below but 22uF is used in the SABRE reference schematic. Which value is correct?

VDD_HIGH_CAP

NVCC_PLL_OUT

Thank you,

Kris

0 Kudos
4,429 Views
igorpadykov
NXP Employee
NXP Employee

Hi Kris

correct is what shows latest i.MX6 Sabre SDP/SDB design schematic.

Best regards

chip

0 Kudos
4,429 Views
krisroh
Contributor I

Thank you for confirmation, Chipexpert.

As I don't have clear solution by DNPing the decoupling caps on i.MX6 internal LDO output, we are going to add a 1uF shunt capacitor on POR_B signal to add 90msec delay.

Would you please let me know if you have any known issues or concerns with this implementation?

Thank you,

Kris

0 Kudos
4,429 Views
igorpadykov
NXP Employee
NXP Employee

Hi Kris

I think you can also prolong POR with that solution too.

I am not aware of any issues with this.

Best regards

chip

4,429 Views
krisroh
Contributor I

Thank you for your support, Chipexpert.

I really appreciate your help as we are going to mass production now.

Best regards,

Kris

0 Kudos