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.
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
(See Figure 2): Moved Config Pins to Much early in Boot (VSNVS) out of the ON-OFF-ON Area. Boots reliably
(See Figure 3): Capture showing that the VDDSOC/ARM_CAP ON-OFF-ON is internal, not a result of VDDSOC/ARM_IN.
Notes for Figures 1 - 3:
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
(See Figure 5): Proper Boot with eMMC and USB activity as expected
Power-up rails/POR_B sequence:
(See Figure 6): Power-up sequence/POR_B
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)
(See Figure 8 - VDDSOC_CAP with 10uF Cap normally boots, but has failed at least once)
(See Figure 9 - VDDSOC_CAP with 0uF Cap boots reliably)
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.
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.
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?
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.
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?
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.
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.
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.
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.
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?
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.
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.
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
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.
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.
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)
VGEN6 is programmed for 2.5V OUT, we do not use default (acceptable range = 1.8 to 3.3V)
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
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 ?
--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