MPC8640D JTAG problem

[lujunbiao]

I use windriver ice 2 to debug 8640D,

in the process "attemping JTAG communication " it display fail.

what might be the problem?

[lujunbiao]

@Alexander

thank you for your reply.

As you said, I do something more to check the state of MPC8640

"ICE 2 display the state of MPC8640D is unterminated"

the boot sequence of MPC8640D is controlled by CPLD on the same board.

boot step1:give power (other than Dn_GVDD Dn_MVREF) to MPC8640D

      check results: OVDD -> 3.0V

                              LVDD TVDD ->2.5V

                              SVDD/ XVDD_SRDSn /AVDD_SDRSn-> 1.05V

                              VDD_COREn -> 1.05V

                             VDD_PLAT ->1.05V

                             AVDD_COREn/ AVDD_LB /AVDD_PLAT->1.05V

boot step 2:give  Dn_GVDD and Dn_MVREF to MPC8640D

       check results:Dn_GVDD->1.84V

                              Dn_MVREF -> 0.9V

                              VTT(for DDR2) -> 0.9V

boot step 3: give sysclk to MPC8640D

        check results: sin clock @100Mhz Vp-p->3.3V

boot step 4:waits 100us then negates hreset to MPC8640D

boot step 5:waits some second then check asleep signal from MPC8640D

        check results: "can not find asleep to be high"

what might be the problem in MPC8640D, please give me some advice to do more test.

[alexander_yakov]

The sequence you specified in more than 2 times shorter than recommended sequence. Please look MPC8641D Reference Manual, Section 4.4.2 for recommended power-on-reset sequence. Please implement everything as recommended in this document.

http://www.nxp.com/assets/documents/data/en/reference-manuals/MPC8641DRM.pdf 

[lujunbiao]

hello alecander

what you said is helpful, according to you suggestion, I read section 4.4.2 and I find step 5 to step 10 on page 4-10 is controlled by 8640 itselft. from the point view of outside cpld or fpga, what it can do is to read the status of asleep signal from 8640.

Is ther e any method to find out the problem on harfware design?

[alexander_yakov]

The sequence you specified is obviously different from recommended. For example:

1. recommended sequence suggests asserting HRESET simultaneously with TRST (in step 2), whereas in your sequence nothing mentioned about TRST

2. At step 3 you are applying only SYSCLK, nothing is mentioned about clock configuration inputs cfg_sys_pll[0:3]

3. at step 4 of your sequence waiting 100 us is not enough, it is also required to apply all POR configuration inputs. These POR inputs must be valid at least 4 SYSCLK clocks before HRESET negation and 2 SYSCLK clocks after. In your sequence nothing is mentioned about POR configuration.

4. Step 9 refers to boot sequencer. As long as nothing is mentioned about POR configuration, if is difficult to predict, if boot sequencer is used or not used.

Missing ASLEEP at step 11 means the device is unable to finish POR sequence because of some mistake - incorrect configuration applied, boot sequencer enabled by mistake, and etc.

[lujunbiao]

@ alexander

1. recommended sequence suggests asserting HRESET simultaneously with TRST (in step 2), whereas in your sequence nothing mentioned about TRST

justin: HRESET and TRST is controlled by COP separately. IF the boot sequence is complete and COP doesn't set TRST, it negates with HRESET simultaneously.

2. At step 3 you are applying only SYSCLK, nothing is mentioned about clock configuration inputs cfg_sys_pll[0:3]

 justin:

This step is crucial to the problem, the original design used PCIe clock generator to output 100Mhz then chip 83026I is used to  transform HCSL clock to LVTTL clock.

I find it difficult to get sysclk whose rise fall time is below 1ns. Is there any crystal oscillator or clock generator can solve this problem?

I used one 66Mhz crystal oscillator as sysclk and 8640 boots successfully, but I need 100Mhz clock to get 400 Mhz MPX clock and 1Ghz core frequency.

Is there any terminal requirements for sysclk near the pin of 8640?

3. at step 4 of your sequence waiting 100 us is not enough, it is also required to apply all POR configuration inputs. These POR inputs must be valid at least 4 SYSCLK clocks before HRESET negation and 2 SYSCLK clocks after. In your sequence nothing is mentioned about POR configuration.

justin: this part is also crucial and it is right as you mentioned. 

[alexander_yakov]

Just to understand your reply properly - do you mean that changing SYSCLK oscillator to 66 Mhz solves startup issue?

[lujunbiao]

Thank you for your reply. I set use 66Mhz crystal oscillator then 8640 boots properly.

but in DDR2 memory test, I enable DDR1 memory controller,disable  DDR2 memory controllerand set the timing configuration register for the contrller.

I fing d1_mdq5 and d1_mdq16 is wrong occassionaly, is there any method I can use to solve this problem?

[alexander_yakov]

I think it will be better to create a new community topic for this DDR-related issue, because it is quite far from initial JTAG issue.

[lujunbiao]

I have start a new topic in community for ddr problem, please go there and give me some advice,thanks.

I wonder whether I can use 100Mhz crystal oscillator  for 8640 , is there any different in hardware design to use 100mhz crystal oscillator? 

Is there any termination requirement for sysclk in 8640?

[alexander_yakov]

According to MPC8640 Hardware Specifications, Table 8, SYSCLK frequency is specified from 66 to 166 Mhz, however note 1 below this table says:

Caution: The MPX clock to SYSCLK ratio and e600 core to MPX clock ratio settings must be chosen such that the resulting
SYSCLK frequency, e600 (core) frequency, and MPX clock frequency do not exceed their respective maximum or minimum
operating frequencies. Refer to Section 18.2, “MPX to SYSCLK PLL Ratio,” and Section 18.3, “e600 to MPX clock PLL
Ratio,” for ratio settings.

There are no termination requirements, but termination must be done so that resulting SYSCLK input clock at the pin must follow electrical characteristics specified in Table 7.

[lujunbiao]

thank you for your reply.

right now, I have tested sysclk @100Mhz and @66Mhz.

Under these two conditions,target board can boots properly and windriver ice 2 can control 8640 to perform further test, but the target board appears to disconnect to the ice2 occassionally and execute "inn" demmand on ice2 , the connection can be rebuilt at once.what might be the problem?

[alexander_yakov]

Debug interface is a part of core, the typical reason for debug interface to not respond to debugger commands is core in stopped mode, not running because of some reason. Please check everything related to proper startup - power supplies, reset configuration settings, input clock and etc.

Have a great day,
Alexander

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------