IMX6 Solo intermittent boot-up failures

cancel
Showing results for 
Search instead for 
Did you mean: 

IMX6 Solo intermittent boot-up failures

8,120 Views
dvona
Contributor II

BACKGROUND:

We have an existing system (custom designed), that exhibits a bootup failure.  The nature of the failure is that the processor appears to not recognize our boot device properly on first time power up, even though our BOOT_MODE and Configuration pins are set properly.

Some notes:

  1. When bootup fails, we notice immediate activity on USB.  We believe this indicates that the wrong boot source has been latched.  Our  system is designed to boot from an eMMC card, but it seems to move immediately to USB boot.
  2. With power on, executing a POR_B causes a proper boot every time.  SO we surmise the issue has to do with power sequencing or some other power on anomaly.

SOLUTION 1: Change from ANA_V2P5V to VSNVS for all boot config pullups (much earlier in sequence and away from strange ON-OFF-ON behavior as exhibited in the following figures)

(See Figure 1): ON-OFF-ON LDOs.  Our Config Pins appear to pull up during this transition.  Boot fails

Figure 1 - LDO ON-OFF-ON 22uF Cap.GIF.gif

(See Figure 2): Moved Config Pins to Much early in Boot (VSNVS) out of the ON-OFF-ON Area.  Boots reliably

Figure 2 - Config Pins Moved to VSNVS.GIF.gif

(See Figure 3): Capture showing that the VDDSOC/ARM_CAP ON-OFF-ON is internal, not a result of VDDSOC/ARM_IN.

Figure 3 - Capture Showing the ON-OFF-ON is internal.GIF.gif

Notes for Figures 1 - 3:

  • Documentation implies the boot config is latched at rising edge of POR_B (i.MX6Dual/6Quad Applications Processor Reference Manual Rev 2, 06/2014)
  • Currently boot resistors are strapped to ANA_V2PV which is safely stable before POR_B rising edge
  • When we change config resistors to VSNVS rail (80ms earlier than ANA_2P5V) we boot reliably
  • This seems to behave as if the boot config is being read/latched at this unstable VDDSOC ON/OFF/ON area

USB ACTIVITY: On Our failure boot-up case, we see USB_OTG doing something early BEFORE POR_B.  eMMC never executes.  If, with power still applied, you perform a second POR_B, then boot from eMMC always happens correctly

(See Figure 4): USB Activity before POR_B failure

Figure 4- USB Activity BEFORE POR_B Failure.GIF.gif

(See Figure 5): Proper Boot with eMMC and USB activity as expected

Figure 5 - Proper Boot with eMMC and USB as expected.GIF.gif

Power-up rails/POR_B sequence:

(See Figure 6): Power-up sequence/POR_B

Figure 6 - Power Up Sequence.GIF.gif

Fix #2 = We have found that reducing the capacitor on VDDSOC_CAP from 22uF to 10uF to 0uF seems to positively impact the boot (NOTE: A recent test showed one failure with a 10uF capacitor, so this is not seen as reliable).  The VDDSOC_CAP signal appears to be the one that contributes to the issue (not VDDARM_CAP).We have tested with 22uF/10uF/0uF on the VDD

(See Figure 7 - VDDSOC_CAP with 22uF Cap Fails)

Figure 7- VDDSOC_CAP ON-OFF-ON with 22uF.GIF.gif

(See Figure 8 - VDDSOC_CAP with 10uF Cap normally boots, but has failed at least once)

Figure 8 - VDDSOC_CAP ON-OFF-ON with 10uF.GIF.gif

(See Figure 9 - VDDSOC_CAP with 0uF Cap boots reliably)

Figure 9 - VDDSOC_CAP ON-OFF-ON with 0uF.GIF.gif

NOTE: We are fully aware that the MAX capacitor value is 22uF including trace capacitance and have improved our design to be as close as mechanically possible to the _CAP pins.  However, even with a 10uF + small trace length we are not booting reliably so we are not convinced this is all of the problem and do not feel this explains the strange on-off-on behavior.


Fix#3 = Burn eFUSES resolves intermittent boot

This will be done, but it does not solve our first time boot problem.  And we also do not understand why the boot fuse method would not be effected in the same way as the config pins.  We know Freescale recommends using the boot fuses in their documentation.  We need to understand WHY this is more reliable.

Answers needed from Freescale:

Q1) What would cause the VDDSOC and VDDARM LDOs to exhibit the ON-OFF-ON at power-up?  Is this a known issue or errata?

Q2) Is the ON-OFF-ON situation somehow causing the apparent early latching?  And how do we mitigate it in such a way that we guarantee a reliable boot from the config pins?

Q3) Why does moving the config pins to a rail that powers up much earlier help the situation?

Q4) What is different about the latching of the configuration when using the eFUSES versus the pull-ups/pull-downs that it would not suffer the same problem? 


In general, our goal is to fully understand the mechanism that is causing this boot failure inside the chip so that we can reliably implement our fix and KNOW that it is going to work.

Labels (2)
53 Replies

1,962 Views
vuhai1904
Contributor II

Hi All

One can try to prolong the PWRON input of PF0100 (not the POR_B), let's see whether it helps.

In my case, I'm using iMX6D with MMPF0100F0AEP on custom board. And some units can't boot up properly on 1st power-on. The PWRON pin setup same as SABRE board: pulled-up to VSNVS with 10k Ohms.

However, I think immediately trigger PWRON when just powered-up device is not a good solution. I tried to prolonging the PWRON by using high pulled-up resistor value, e.g 100k and add shunt capacitor, e.g 1~4.7uF. With this change, PWRON takes more than 500ms to reach VIH value (0.8*VSNVS or 2.4V typically). And iMX6 can always boot up properly.

0 Kudos

1,962 Views
xmygkj
Contributor I

hello all

we meet the same problem in our hardware,is there a solution for this issue?

0 Kudos

1,962 Views
krunalshah
Contributor I

Hello All,

We have the same issue we are using imx6 UL with AS4C256M16D3L-12BCN from Alliance memory, As soon as we provide power to the system, I am expecting the board to boot from eMMC.  We need to issue a 2nd POR_B to properly boot from eMMC.

Is there any root cause for this issue? How to solve it?

0 Kudos

1,962 Views
sohara
Contributor I

Check to see if you have it wrongly trying to boot from USB.  If yes it's the same bug.  They never really disclosed the root cause by the way, so we were stuck to make many schematic changes to make it less likely.  Problem's inside the part though no doubt.

0 Kudos

1,962 Views
dismirli
Contributor I

Hi Shawn, I'm designing a board which will boot from eMMC. I'm reading about this issue, and will try to avoid it. Have you found the root cause, and any workaround?

Thanks!

Diego.

0 Kudos

1,962 Views
guslabao
Contributor III

Hi All,

Our board design based on IMX6SOLO and MMPF0100F6AEP is experiencing the same issue, where a 2nd POR_B is required to properly boot from eMMC.

As soon as I provide power to the system, I am expecting the board to boot from eMMC.  We need to issue a 2nd POR_B to properly boot from eMMC.

Is there are found solution for this issue yet.

Thanks,

Gus

1,962 Views
joissrinidhites
Contributor II

Hello All,

  We have built custom hardware with i.mx6 quad core processor and MMPF0100F0AEP as PMIC.

  we have built 500 boards and we are observing the same issue in 100 boards.

  We have also done similar trials on our hardware and still the same issue exists.

  What is the solutions for this? It is very urgent.

Regards,

Srinidhi jois

0 Kudos

1,962 Views
rkim
Contributor II

Was the root cause ever found for this?  I'm seeing the same kind of problem (a 2nd POR_B reset is needed to boot from the SD card) on our IMX6Q-based custom board.

Thanks,

Rich

0 Kudos

1,991 Views
igorpadykov
NXP TechSupport
NXP TechSupport

Hi Dan

you can try to prolong POR, say up to 0.8-1 sec. and check if that helps.

In i.MX6S there is no "ANA_V2P5V" signal, what it is this signal connected to ?

In general, SNVS (VDD_SNVS_CAP) power should be powered first and it should

be very quite and well filtered.

Any other power is provided later SNVS, while boot signals belong to SNVS power domain.

So SNVS will see unexpected current (voltage spike) drawn from boot resistors

(when  "ANA_V2P5V" start-up), so SNVS power gitch detector can reject boot

if this is secure boot.

Best regards

igor

0 Kudos

1,991 Views
sohara
Contributor I

 

ANA_2P5V rail is generated by the PMIC "VGEN6_OUT", this rail comes up about 72ms after VSNVS and about 14mS before we de-assert POR_B.

We release POR_B about 14mS after ANA_2P5 rail, documentation states in multiple places that boot resisrors get latched at POR_B release.

Can you provide more insight about SNVS getting unexpected spike from ANA_V2P5 pull-resistors?  Could it be possible for this glitch to get something in such a bad state that 1st POR_B does not work correctly but 2nd POR_B always works correctly?

Could our problem be related to the VDDSOC_CAP turning ON-OFF-ON?  Why is this ON-OFf-ON happening?

0 Kudos

1,991 Views
igorpadykov
NXP TechSupport
NXP TechSupport

what PMIC are you using, in attached diagram VDDARM_IN,VDDSOC_IN

provided simultaneously, thus huge current soike may occur -

this may be reason for "turning ON-OFF-ON".

For i.MX6SDL usually MMPF0100 "F0" is used, it gives powering

VDDARM_IN,VDDSOC_IN in different time steps.

0 Kudos

1,991 Views
sohara
Contributor I

We are using MMPF0100NPEPR2, we cannot delay 0.8sec without PCB layout change, maximum POR_B delay is 32ms.

All supplies are stable before POR_B release.   Something is in latch-up condition and 1st POR_B does not work, 2nd POR_B seems to always work.

We will try test to to separate VDDARM_IN and VDDSOC_IN although that still would not explain why 1st POR_B does not work.

0 Kudos

1,991 Views
igorpadykov
NXP TechSupport
NXP TechSupport

1st POR_B may not work due to

large power spikes, since board capacitors

start to charge. Second POR_B resets processor

when all capacitors are charged so there are no power

spikes.

0 Kudos

1,991 Views
sohara
Contributor I

1st POR_B is 14mS after this glitch area, all external capacators are fully charged confirmed by scope, you don't think that is enough time internally for some reason?

After glitch do we need to deassert/assert/deassert POR_B?   (PMIC is not designed to do that,We cannot do that easily.)

Also we cannot re-program PMIC very easily, we need to program new PMIC and send board out for part change.

0 Kudos

1,991 Views
igorpadykov
NXP TechSupport
NXP TechSupport

could you try to prolong POR, say up to 0.8-1 sec. and check if that helps ?

It can be done manually since MMPF0100 RESETBMCU is open drain.

0 Kudos

1,991 Views
sohara
Contributor I

We performed this test, we disconnected PMIC reset and ran external reset, 1st POR_B de-assert at about 5 seconds delay still does not work, 2nd POR_B de-assert at second 5 seconds delay works/boots successfully.  That's why we ask questions about what could get into such a bad state from VDDSOC_CAP ON/OFF/ON sequence?  So bad that 1st simple POR_B de-assert does not correct.  Seems some module seems to require POR_B deassert/assert/deassert to get out of the problem scenario.

0 Kudos

1,991 Views
igorpadykov
NXP TechSupport
NXP TechSupport

you said that :

"ANA_2P5V rail is generated by the PMIC "VGEN6_OUT""

VGEN6=2.8V on MMPF0100N part, what is real voltage on that rail ?

How connected VDDHIGH_IN, what MMPF0100 power is used for it ?

Also, are you using boot signals for other purposes (such as parallel NOR) as in

Figure 2-1. Boot configuration for development mode IMX6DQ6SDLHDG

One can easily to check if boot signals are sampled correctly by

stopping processor, attaching jtag and checking SRC_SBMR1,SRC_SBMR2

IMX6SDLRM 60.7.2 SRC Boot Mode Register 1 (SRC_SBMR1)

0 Kudos

1,991 Views
sohara
Contributor I


VGEN6 is programmed for 2.5V OUT, we do not use default (acceptable range = 1.8 to 3.3V)

Measures ~2.5V

VIN3 = about 3.8 to 4.1V

VGEN3=VDDHIGH_IN1/VDDHIGH_IN2 (connected together)= 2.8V (22uF, 220nF, 220nF) - NO connections to anything else

VDDHIGH_CAP1/VDDHIGH_CAP2(connected together)=program out = 2.8V (22uF, 220nF, 220nF) - NO connections to anything else

Boot signals are all fixed loaded/No loaded for eMMC boot

We cannot check boot signal sampling in failure case, failure case is completely dead behavior

0 Kudos

1,991 Views
igorpadykov
NXP TechSupport
NXP TechSupport

so VDDHIGH_IN=VDDHIGH_CAP=2.8V, have you connected them together?

Having VDDHIGH_CAP= 2.8V" violates Table 8. Operating Ranges IMX6SDLCEC :

NVCC_LVDS_2P5, NVCC_MIPI max.= 2.75V

as VDDHIGH_CAP powers NVCC_LVDS_2P5, NVCC_MIPI

VDDHIGH_CAP=VDDHIGH_VPH=GEN_2V5 on SPF-27417

Sabre SDP schematic

"dead behavior" means jtag can not attach to

processor ? Is 24MHz working in that case ?

0 Kudos

1,991 Views
sohara
Contributor I

--so VDDHIGH_IN=VDDHIGH_CAP=2.8V, have you connected them together?
NO, VDDHIGH_IN1 connected to VDDHIGH_IN2  (measured = 3.0V)
VDDHIGH_CAP1 connected to VDDHIGH_CAP2 (measured = 2.55V, also connects to NVCC_LVDS2P5 ball and PCIE_VPH ball)

Having VDDHIGH_CAP= 2.8V" violates Table 8. Operating Ranges IMX6SDLCEC :
I made a mistake, we actually have 2.55V on VDDHIGH_CAP
We are using MCIMX6S5DVM10AB
I don't believe we have any violation.

--NVCC_LVDS_2P5, NVCC_MIPI max.= 2.75V
correct PCIE_VPH and NVCC_LVDS2P5 connected to VDDHIGH_CAP which is 2.55V


--"dead behavior" means jtag can not attach to processor ?

-- Is 24MHz working in that case ?
Correct, 24 MHz is working, at glitch time processor is *immediately* stuck trying to boot from USB-OTG for some wrong reason

0 Kudos