DDR2 data lines not being driven in write cycle (MPC8377)

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

DDR2 data lines not being driven in write cycle (MPC8377)

跳至解决方案
3,123 次查看
mvonahnen
Contributor II
Has anybody seen an issue where the MQxx data lines do not drive the bus in a write cycle?  We have a new board we have designed.

We are using 64 bit bus,  using 4x MT47H64M16HR-3IT memory chips from Micron.  We have tried running the DDR2 at a slow speed just to verify operation, so we have configured it for a 133 MHz clock rate.  We are seeing all of the control signals and captured a write cycle with our oscope / logic analyzer.  Every thing looks good, except for the data lines do not appear to drive.  When ODT is enabled, the data lines are at 0.9 V while MDQS is toggling.

We suspect pretty much everything in the design, but we have verified the following things:

1.  All of the 1.8 V supply pins have power.
2.  The processor is getting clocks.
3.  The output DDR2 clocks are what are expected.

We are configuring the reset configuration words from the CodeWarrior USB TAP. 

I have attached our measurement.  Note, the CS# / Clock relationship shown by the logic analyzer traces does not represent the actual timing.

Any suggestions on things to go look at?

atlas_wr_all_ones.jpg
Message Edited by t.dowe on 2009-10-20 01:03 PM
0 项奖励
回复
1 解答
1,743 次查看
mvonahnen
Contributor II
Some additional information.  All 8 MDQS and MDM signals are driven for access, even if we are doing byte level accesses.

在原帖中查看解决方案

0 项奖励
回复
2 回复数
1,744 次查看
mvonahnen
Contributor II
Some additional information.  All 8 MDQS and MDM signals are driven for access, even if we are doing byte level accesses.
0 项奖励
回复
1,743 次查看
mvonahnen
Contributor II
The problem was found, a pull down was mistakenly placed on CFG_LYNX_TEST (which shares a pin with USB1_STP).  This caused the part to go into a partial test mode.  Removing the pull down fixed the issue.
0 项奖励
回复