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:
- 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.
- 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
(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:
- 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
(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.
