sorry for late answer but It tooks time to find the event trigger on the oscilloscope.
5) attached you’ll find the binary image currently used in all our units.
6) all the items that could pull it down are logic gate (U41) and FPGA (U34): we removed U41 logic gate (if faulty it could behave unexpectedly) but the unit keeps resetting. Moreover the FPGA is volatile memory type and in this phase is not programmed (it will be programmed 0.9s after the CPU power up) so it cannot pull down the RESET_REQ_B.
Below you'll find the waveform of RESET_REQ_B and ASLEEP during normal startup and during reset event startup.
Thank you for reply.
Giacomo.
Hi Ufedor,
1) AVDD_SD1_PLLn supply filter are in schematics page 3 (and reported in picture below). I summarize our standard failing boards filter:
As seen our implementation seems to fulfill the requirement of CPU datasheet sec. 4.2.2 as below:
- The AGND_SD1_PLL1, AGND_SD1_PLL2 filter caps seems correctly chosen;
- The local filter grounds AGND_SD1_PLL1, AGND_SD1_PLL2 are connected directly to AA16, AA20 balls, respectively (we followed evaluation board pinout, is they were not documented in CPU datasheet); then they are connected to board-level GND;
- Our +VDD_DDR3=1.35V rail is supplied through on board switching regulator (U7, cod. NCP3135) with output caps 100nF-0402-X7R || 3x 100uF-1210-X7S;
I think our standard implementation is NOT OK for following points:
- The 3.3n caps are 0603 instead that required 0402 size; moreover they aren’t near the AB16, AB20 balls;
When I understood this problem I changed actual failing product as follows:
- We added a 3.3n-0402 cap directly above the vias related to AB16-AA16 ball;
- We added a 3.3n-0402 cap directly above the vias related to AB20-AA20 ball;
The result after this mod is that the problem is not solved.
But I have a residual doubt about datasheet meaning: our actual AGND_SD1_PLL1, AGND_SD1_PLL2 signal are supplied from board-level supply +VDD_DDR3=1.35V, NOT from X1VDD as seems to be required from datasheet; but we are not sure of this requirement (“AVDD_SDn_PLLn should be a filtered version of XnVDD”) as we copied from Evaluation board design. Do NXP intend to have the board-level 1.35V to supply X1VDD and then X1VDD to supply S1VDD or can we use the board-level 1.35V to supply both X1VDD and S1VDD?
2) The COP interface not used during the product use, we use it only 1 time during initial system programming. For this reason during the acquisitions below the COP connector (connector J1) was not paired with an external TAP interface.
So during measure COP_JTAG_TRST_3.3V_B was tied to 0V with pull-down (R26). -> Even if it should be a pull-up according fig. 80 on datasheet, don’t know if it could cause problems to CPU in normal operation...
Being an input of logic gate U35, it causes TRST_B=JTAG_TRST_B_1.8V to be 0V.
The TRST_B=JTAG_TRST_B_1.8V waveform is the C3 channel in the following photos.
| Normal startup | Failing startup (CPU RESET_REQ asserted) |
 Normal/correct startup (C1=24V trigger, C2=RESET_REQ_B, C3= TRST_B) | Forced CPU reset startup (C1=24V trigger, C2=RESET_REQ_B, C3= TRST_B). The forced reset is fictitiously obtained with PLL1=powered down as it’s a rare and random problem. |
Below you find also the match between our schematics CPU reset logic and fig.80 on CPU datasheet.
Thanks you.
Giacomo
Dear Ufedor,
I've done some measurements.
3) The SD1_REF_CLK1_P/N waveform is reported in figs. below and has V_pkpk=1.24V. The Vpkpk is obtained from a AC-LVPECL waveform with V_pkpk=1.8V further reduced of 70% with a series resistor 22ohm to be compliant with CPU requirements (V_pkpk < 0.8V).
4) the PORESET_B assertion duration after all supplies are stable is 213ms (both if the system starts up normally, see fig. 1, or if the systems fails to startup, see fig. 2).
5) the PORESET_B related logic is:
if [(EN_HRESET_REQ_B = 0 and HRESET_REQ_B=0) or FPGA_HRESET_REQ_B=0] then:
CPU_HRESET_B=0 for 200ms;
If PS_RESET_B=0 then:
CPU_HRESET_B=0;
if CPU_HRESET_B=0 or COP_HRESET_3.3V_B=0 then:
PORESET_B=0;
As explained below we identified the exact conditions that activated the PORESET_B=0 in case of failing startup: see bold condition above.
What’s happen during normal startup (see fig. 1):
It takes about 213ms from the time all supplies are stable (in the picture I put only VDD_DDR3=1.35V [trace C1, fig.1,2] supply because it’s the last supply to stabilize) to the first PORESET_B: 0->1 [trace C2, fig.1,2] POR transition. This 213ms delay is originated by voltage monitor U31 (STM6905) which, during this time, keeps its output PS_RESET_B=0; moreover DS2 keeps CPU_HRESET=0 [trace C4, fig. 1,2] causing U37 to keep PORESET_B=0 after initial stabilization.
Until this moment HRESET_REQ_B [trace C3, fig. 1,2] was not asserted.
Now, 213ms after all supplies are stable, voltage monitor U31 releases PS_RESET_B, then DS2 releases CPU_HRESET_B(*) [trace C4, fig. 1,2], so they both have a transition 0->1; at the same time U37 releases PORESET_B [trace C2, fig. 1,2].
(*) at this moment CPU_HRESET_B is already been released by supervisor U39 (STM6322) which has a lower timeout, 200ms.
At 948ms since supplies are stable we see a EN_HRESET_REQ_B=1->0 transition (as in fig. 6): it’s the GPIO used to enable the CPU reset request.
From this moment there aren’t any other transitions on CPU_HRESET_B, PORESET_B, HRESET_REQ_B signals. In this case the system works normally.
What’s happen during system startup fail event (see fig. 2,3):
It takes about 213ms from the time all supplies are stable (in the picture I put only VDD_DDR3=1.35V [trace C1, fig.1,2] supply because it’s the last supply to stabilize) to the first PORESET_B: 0->1 [trace C2, fig.1,2] POR transition. This 213ms delay is originated by voltage monitor U31 (STM6905) which, during this time, keeps its output PS_RESET_B=0; moreover DS2 keeps CPU_HRESET=0 [trace C4, fig. 1,2] causing U37 to keep PORESET_B=0 after initial stabilization.
Until this moment HRESET_REQ_B [trace C3, fig. 1,2] was not asserted.
(#)
Now, 213ms after all supplies are stable, voltage monitor U31 releases PS_RESET_B, then DS2 releases CPU_HRESET_B(*) [trace C4, fig. 1,2], so they both have a transition 0->1; at the same time U37 releases PORESET_B [trace C2, fig. 1,2].
(*) at this moment CPU_HRESET_B is already been released by supervisor U39 (STM6322) which has a lower timeout, 200ms.
The first difference of fig.2 (compared to fig. 1) is that, after 213+3ms since supplies are stable (only for first event) or 3ms since this PORESET_B: 0->1 transition the CPU(**), yet out of POR state, drives the first HRESET_REQ_B: 1->0 [trace C3, fig. 2,3] transition.
(**) we suppose that’s the CPU that drives the HRESET_REQ_B transition because HRESET_REQ_B is connected to:
- CPU -> we suppose that drives this transition;
- FPGA -> the FPGA doesn’t drive the signal as it’s not programmed at this moment;
- U41 -> U41 doesn’t drive the signal because - after we cut its input EN_HRESET_REQ_B and added there a pullup - we could still measure the same transition on HRESET_REQ_B CPU side.
After 948ms since supplies are stable (only for first event) or 734ms since this PORESET_B: 0->1 transition there is the EN_HRESET_REQ_B=1->0 transition (as in fig. 4), as in the normal startup case: as HRESET_REQ_B=0 (as told above) then U41-U40-U39-U37 logic chain lead to a PORESET_B: 1->0 transition and the CPU goes for the first time in a unwanted POR state (see fig. 2,3).
Side note: we excluded that the PORESET_B: 1->0 transition is unstable voltage supply (because PS_RESET_B = 1 is stable for all time).
After 948ms+0.3ms since supplies are stable (only for first event) or 734ms+0.3ms since this PORESET_B: 0->1 transition we see a EN_HRESET_REQ_B=1->0 transition as in fig. 4, probably due to CPU POR state.
The waveforms explanation continues at fig. 5:
after further 190ms in other words after 948+190ms since supplies are stable (only for first event) or 734ms+190ms since this PORESET_B: 0->1 transition, as in fig. 5, we see the first PORESET_B: 0->1 transition and the CPU exits for the first time from the unwanted POR state.
(#)
From this moment the waveforms repeat periodically between the (#) marks with T=926m.
NOTE: if we artificially shutdown SD1_REF_CLK1 the system fails EVERY startup exactly in the same way of above description.
Do you have all information useful to reply? We are in a hurry because we need to proceed with new production batch.
One question we need fast reply is: is it ok to supply AVDD_SD1_PLL1 from our board-level +VDD_DDR3=1.35V rail (like actual board) or should we supply it from X1VDD CPU balls (e.g. AC12)? It's not clear from manual.
Thank you,
Giacomo.
------------------------
Figures:
Normal startup:
FIG.1: Normal startup (C1=VDD_DDR3, C2=PORESET_B, C3=HRESET_REQ_B, C4=CPU_HRESET_B)
FIG. 6: Normal startup (C1=VDD_DDR3, C2=PORESET_B, C3=EN_HRESET_REQ_B, C4=U41_OUT)
Wrong startup – first unwanted POR event (“CPU reset”):
FIG. 2: Wrong startup - first unwanted POR event (C1=VDD_DDR3, C2=PORESET_B, C3=HRESET_REQ_B, C4=CPU_HRESET_B)
FIG. 3: Wrong startup - first unwanted POR event (C1=VDD_DDR3, C2=PORESET_B, C3=HRESET_REQ_B, C4=CPU_HRESET_B)
FIG. 4: Wrong startup - first unwanted POR event (C1=VDD_DDR3, C2=PORESET_B, C3=EN_HRESET_REQ_B, C4=U41_OUT)
Wrong startup – following unwanted POR events (“CPU reset”):
FIG. 5: Wrong startup - further unwanted POR periodical events (C1=VDD_DDR3, C2=PORESET_B, C3=HRESET_REQ_B, C4=CPU_HRESET_B)
SerDes reference clock amplitude looks greater than specified in the processor's Data sheet:
HRESET_B should not be driven externally during POR - only PORESET_B.
You wrote:
> is it ok to supply AVDD_SD1_PLL1 from our board-level +VDD_DDR3=1.35V rail
It is possible to use any 1.35V supply if all requirements and specifications of the processor's Data Sheet are fulfilled.
Dear Ufedor,
I really appreciate you speed on answers.
I reply point to point:
" SerDes reference clock amplitude looks greater than specified in the processor's Data sheet:"
Sorry if I wasn' t clear but our 1.26V signal was SD1_REF_CLK_P - SD1_REF_CLK_N alias differential peak-peak voltage (Vod_pkpk) so it's double relative to single ended signal SD1_REF_CLK_P - GND (Vod_pk). So it should be correct as its single ended equivalent is Vod_pk=0.63V <0.8V as datasheet request.
"HRESET_B should not be driven externally during POR - only PORESET_B."
We don't drive HRESET_B externally: on our boards this signal is named SRESET_1.8V_B and may come:
- from FPGA (during reset event the FPGA is not yet operational); or
- from JTAG TAP connector (J1, pin11) as 3.3V signal further translated to 1.8V with level translator (U12);
If I try to depoulate R124 (adding pullup at pin 1) this is the result: it shows that HRESET_B CPU signal is not pulled low externally.
Prehaps our signal name induced you in confusion? On my previous post I talk about " CPU_HRESET_B", " HRESET_REQ_B" but these signals are the logic related to PORESET_B not to HRESET_B. Our schematics on pages 2 and 4 is clarifying.
" It is possible to use any 1.35V supply if all requirements and specifications of the processor's Data Sheet are fulfilled."
So the datasheet sentence "AVDD_SD1_PLL1n should be a filtered version of X1VDD" actually means that " AVDD_SD1_PLL1n should be a filtered version of X1VDD source voltage"? In this case our supply architecture is compliant.
Do you have any other advice?
Post scriptum: we are re-designing the SerDes differential traces: which are the max acceptable crosstalk limits (NEXT, FEXT) to be used for QSGMII? We saw the QSGMII spec but it talks only about SDD11,SDD22, SCC22 but nothing about crosstalk.
Thank you so much,
Giacomo.
Dear Ufedor,
here are the voltage measured on AVDD_SD1_PLL1 supply: in particular the positive terminal was R63,pin2 and negative terminal was on local GND near AA16 CPU ball. I measured in input filter not on balls as in advice in datasheet.
I measured with a FET low cap 1GHz probe and the worst case waveforms show that we are within 1.35+/-65mV:
- Vmax=1.365V at startup overshoot;
- Vmax= 1.359V during power on;
- Vmin=1.319V at startup or during power on;
This is the worst case with CLK_OUT=ON.
The other unit I measured with CLK_OUT=OFF show less noise, as below:
