Our HWPA team raised an issue that the POR_B(ResetBMCU) from PF3000 to IMX7 is deasserted before the external clock (32k/24MHz) stable. They think it is better to be deasserted after the clock source is stable but I do not find any request about this in HW design guideline.
Also, the reset coming from the PF3000 that I can not extend its delay time from 2mS to longer. So, if this is requirement, I do not have chance to meet it (CLK stable then reset is deasserted. )
Do I ignore the request from our PA team?
Hello,
Section 4.4 (Avoiding reset pitfalls) of the Hardware Development Guide for i.MX7 states:
Follow these guidelines to ensure that you are booting using the correct boot mode.
• During initial power on while asserting the POR_B reset signal, ensure that 24 MHz clock
is active before releasing POR_B.
• Follow the recommended power-up sequence specified in the i.MX7 data sheet.
• Ensure the POR_B signal remains asserted (low) until all voltage rails associated with bootup are on.
http://www.nxp.com/assets/documents/data/en/user-guides/IMX7DSHDG.pdf
So, it is good practice to assert the POR till clocks (at least 24 MHz) are active.
Situation with 32 KHz clock is easier, since on-chip 32 kHz RC oscillator starts up
faster than external 32 KHz crystal oscillator. At power up, RC oscillator is utilized.
After crystal oscillator is stable, the clock circuit switches over to the crystal oscillator
(if applied) automatically.
Have a great day,
Yuri
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Yuri,
If we use the PMIC POR_B(ResetBMCU) as the power soruce, and we use the external crystal which is drived by IMX7D. The external crystal inital timing is decided by IMX7D. I mean the condition is as same as the Saber board and I believe the Saber board should also have the same condition (deasserted before the clk stable) as our design.
I mean, in your saber board, how do you meet the design guideline?
The reference design sometimes may not satisfy design rules, since they are created simultaneously
with documentation and some recent requirements are not met. Nevertheless, our boards are working
and therefore may be used as base for customer's designs.
~Yuri.
Becasue we are close to mass production, how to estimate the risk if we do not meet the desgin guideline?
To be fully on safe side - it would be better to to meet the requirement,
that 24 MHz clock should be active before releasing POR_B.
~Yuri.
Hi Yuri,
We found some decription in the "IMX7DRM" document. Does it mean the internal POR will also take the control if the external POR is not used or held high. ((((6.2.5.2 Internal POR If the external SRC_POR_B signal is not used (always held high or left unconnected), the processor defaults to the internal POR function (PMU controls generation of the POR based on the power supplies). )))))
So, the external POR seems to be not the critical part for crystal initial. Do I misunderstanding something?
====
6.2.5 Power-On Reset and power sequencing This module generates an internal POR_B signal that is logically AND'ed with any externally applied SRC_POR_B signal. The internal POR_B signal will be held low until all of the following conditions are met: • 4ms after the external power supply VDDHIGH_IN is valid • 1ms after the VDD_SOC_CAP supply is valid The 4ms and 1ms delays are derived from counting the 32kHz RTC clock cycles; the accuracy depends on the accuracy of the RTC. When the RTC crystal is either absent or in the process of powering up, an internal ring oscillator will be the source of RTC, which is not as accurate as the crystal.
6.2.5.2 Internal POR If the external SRC_POR_B signal is not used (always held high or left unconnected), the processor defaults to the internal POR function (PMU controls generation of the POR based on the power supplies). If the internal POR function is used, the following power supply requirements must be met: • VDD_ARM_IN and VDD_SOC_IN may be supplied from the same source, or • VDD_SOC_IN can be supplied before VDD_ARM_IN with a maximum delay of 1 ms.
6.2.6.1.2.2 POR (SRC_POR_B) SRC_POR_B is an external reset signal. When the chip is powered up, the reset signal is passed through the POR_B pin indicating power-up sequence. The SRC resets the entire chip including the JTAG (SJC) module. All SRC registers will be reset during the POR sequence. As soon as SRC_POR_B occurs, all resets are asserted and the entire chip is reset by SRC. The SRC_POR_B is stretched for 2 XTALI cycles and the stretching sequence takes place after 2 XTALI clocks of POR_B pin deassertion. The sjc_por_rst_b and srtc_rst_b signals are deasserted together with SRC_POR_B signal. Those outputs are also deasserted after the stretching of SRC_POR_B has deasserted. Once the above resets deassert, system_early_rst_b reset is deasserted after 2 XTALI clocks. The system_early_rst_b is used for the CCM and PLL-IPs to start generating PLL clock ouputs and the system root clocks. When the system root clocks are ready, the CCM will assert system_clk_ready signal. This signal is generated during the start sequence in the CCM and it involves the preparation of the PLLs to generate clock roots for functional operation. SRC then enables OCOTP_CTRL and fusebox clocks, so that fuses can be loaded to OCOTP_CTRL. • SRC will prepare the boot information • After 8 ipg cycles, resets to all modules will be de-asserted • After 8 ipg cycles, system clocks will be enabled (en_system_clk).
Hello,
Yes, i.MX7 provides internal POR, if there is no external one.
As has been mentioned, it is good practice for assurance to assert the POR till clocks are active.
Historically it is rises from some issues in i.MX6, where using low accuracy internal 32 KHz clock
cases some boot problems.
Regards,
Yuri.
So, the suggestion coming from the IMX6 and the IMX7 internal POR should cover this but NXP still suggest to follow the same desgin suggestion as the IMX6 avoid the risk.
Correct.