Hi,
What conditions should be met in order the T1040 to assert HRESET_B and deassert RESET_REQ_B after assertion of PORESET_B (for example, after RESET_REQ_B assertion during POR sequence)?
I'm observing that both HRESET_B and RESET_REQ_B do not change their states after PORESET_B assertion in my custom board:
Blue - PORESET_B
Magenta - RESET_REQ_B
Green - HRESET_B
BR,
Denis
已解决! 转到解答。
Finally I have solved this puzzle!
Unlike other POR config inputs (cfg_rcw_src[0:8]), the cfg_eng_use[0:2] inputs must be in a valid state not only at the moment of POR deassertion, but all the time during the PORESET_B assertion.
Finally I have solved this puzzle!
Unlike other POR config inputs (cfg_rcw_src[0:8]), the cfg_eng_use[0:2] inputs must be in a valid state not only at the moment of POR deassertion, but all the time during the PORESET_B assertion.
These setup and hold times are relative to negation of PORESET_B, that is to the moment of PORESET_B deassertion!
There's nothing about POR config inputs, and particularly about cfg_eng_use[0:2], during PORESET_B assertion, besides the last 4T (=40ns @ Fsysclk=100MHz), isn't it?
Are you trying to convince me that the documentation is clear enough?
"Some signals must be driven high or low during the reset period. For details about all the signals that require external pull-up resistors, see the data sheet document." - are you saying about this?
Well, let's see:
Which of these notes are definitely saying about the need to drive the signals during all time while the PORESET_B is active?
On the other hand, the Design Checklist says that:
Input setup time for POR configs with respect to negation of PORESET_B (min) 4 SYSCLKs
Input hold time for all POR configs with respect to negation of PORESET_B (min) 2 SYSCLKs
Maximum valid-to-high impedance time
for actively driven POR configs with respect to negation of PORESET_B (max) 5 SYSCLKs
I have had setup time of around 800us and hold time of around 50ns(~5Tclk) for both the cfg_eng_use[0:2] and cfg_rcw_src[0:8] at the waveform in the starting post. Why the HRESET_B and RESET_REQ_B behavior after PORESET_B assertion was nevertheless wrong?
The problem is already solved, and now its solution seems quite straightforward, but I still think that some important aspects in documentation are not clear enough or aren't mentioned at all, and sometimes are wrong.
Thank you anyway for your help.
BR,
Denis
Hi Fedor,
Hard-coded RCW option has been used for the waveform shown.
When using e.g. I2C as RCW source, the HRESET_B is not deasserted in accordance with RM (valid RCW data are not applied yet), but again the RESET_REQ_B is not deasserted after the PORESET_B assertion.
BR,
Denis
It is required to doublecheck that all notes after the "Table 1. Pinout list by bus" in the "QorIQ T1040, T1020 Data Sheet" are fulfilled, power sequence is correct and all clocks are applied.
I have only DIFF_SYSCLK ans SD1_REF_CLK1 routed and applied. SYSCLK and DDRCLK are pulled down. Could it be the source of problem?
Обновлено
It seems the RESET_REQ_B is deasserted when HRESET_B is asserted externally (w/o PORESET_B)