How can I debug my DDR2 memory design?

Hi
I have 2 protoypes here of a design that has AT91SAM9G45 connected to 2 x 8 bit DDR2 memory chips (chip1= DQ0-DQ7 and chip2=DQ8-DQ15).

1 board works and the other does not. It may be a marginal design but I am not sure yet.

Long story short, the RAM chips to not output any read data. They just remain hiZ. Both of them at the same time during a 16bit read remain HiZ.

I only have a 4 channel Agilent oscilloscope (MSO) at hand for debugging.

Logic would have it that whatever is causing the issue would have to be on common lines that go to both chips. That is speculation of course.

I see the relevant control lines doing stuff at a fast rate, same as the working board but the chips are not driving the bus.

It is unclear to me if these chips should even respond if they are not correctly configured. If that is the case, then maybe I have an issue with writes rather than reads.

I simply don't know more than that and I am hoping that someone here can give me a few pointers on what else I can do here with the oscilloscope.

I can issue reads and writes from a test program but even that is wweird because somehow I think the cpu does multiple reads / writes and stuff instead.

Can any one please give me an idea how to go about getting this to work?
Power is ok and clk is 133MHz.

Best regards
X

Hi
Some part may not soldered well, probably DDR2 termination or chip decoupling Cap.
Best Regards

Miralipoor said:

Hi
Some part may not soldered well, probably DDR2 termination or chip decoupling Cap.
Best Regards

Click to expand...

Good point.
I have thought about that as well.
I have had the cpu replaced already and I buzzed out all the termination resistors as far as possible. Seems ok.
I have also had the 2 RAM chips and cpu X-rayed and nothing noteworthy was found either.

I am now leaning towards getting the RAM chips removed and replaced with others.

If that does not help I am in trouble.

My Signal Integrity simulation has not shown anything out of order either and of course I routed everything according to the app notes with matched length, imepedance setc.


What also suprises me is that the CPU only ever seems to read from the RAM bus once for a given address.

I have an infinite loop reading from address 0 and showing that value on the debug port.

If I short some datalines to ground when starting this loop, the correct bits are read low, forever. Even when I short other datalines low, I still read the original value on the bus.

Does a DDR2 controller have a built in cache somewhere? I have turned off all cache on the CPU but this still persists.

I makes it even harder trying to debug a RAM chip that does not want to read.

Regards
X

from you description,

It seems like READ is not working, But WRITE is working.
How do you know WRITE is working..? After writing have you read them and verified...

How do you sure tat data lines are Hi-Z have you measured the voltage of the data lines.... Your data lines switch at 266Mhz, Probe and DSO should be capable enough.

Confirm RAM ic's alive or not? Like can you able to see During READ DQS# signal outputs any signal (or) If you have any Ferrite bead in power line, try to see whether RAM ic's are taking reasonable current when IDLE.

I assume in both boards, the Atmel Controller's registers were programmed to the same values and they also verified by reading.

In 2 Prototypes, one is working and another is not working means general case of assembly issues like bad soldering/dry soldering ( sense the heat with the fingers on top of IC ) or IC damages.

I am just asking these details to make things clear...

malli_1729 said:

from you description,

It seems like READ is not working, But WRITE is working.
How do you know WRITE is working..? After writing have you read them and verified...

How do you sure tat data lines are Hi-Z have you measured the voltage of the data lines.... Your data lines switch at 266Mhz, Probe and DSO should be capable enough.

Confirm RAM ic's alive or not? Like can you able to see During READ DQS# signal outputs any signal (or) If you have any Ferrite bead in power line, try to see whether RAM ic's are taking reasonable current when IDLE.

I assume in both boards, the Atmel Controller's registers were programmed to the same values and they also verified by reading.

In 2 Prototypes, one is working and another is not working means general case of assembly issues like bad soldering/dry soldering ( sense the heat with the fingers on top of IC ) or IC damages.

I am just asking these details to make things clear...

Click to expand...

Hi

Thanks for asking!

I cannot state that write is working. There is no way to tell.
Remember the joke about the Write only memory datasheet in the old National databooks or was it SG Thomson?...

I can say that the lines remain Hi-Z because on a working board, I can see (measure) the data lines being pulled high or low during a read cycle.
I have a 300MHz 2GAa/s MSO scope and it is quite capable of meauring this.

I do NOT get READ DQS# signals on either chip during read.

I can't verify the current consumption but I can say that the chips both go to the same operating temperature as the working board during idle.

I cannot syncronise the scope to any read operations as I can't trigger on multi signal commands. I do not know enough about this interface to do any better. I do not have access to a state analyser.

Configuration and test code is identical for working and non working board.

Best regards
X

You said 1 board is working, so, have you checked complete reads,writes and initialization with this. So,that we can take this configurations(all registers and other stuff) as reference.
In Non-Working board,
I assume powers are OK within specifications (mainly Vref to both DDR2 and controller)
Can u check CKE# to go HIGH and CK/CK# is running, during interface initialization as per Jedec spec.

In JESD79-2F page 27, there is a initialization procedure,
mostly programming EMR registers require either of BA(bank address inputs) toggling, or A10 toggling..

Check whether A10 or any Bank address signals are toggling or not?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If we are confident that assembly is not an issue...then it's OK....
Otherwise please check impedance's of rails VDD,VREF and important lines like DQS,any of DQ, any of address lines to see internal shorts.....
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

malli_1729 said:

You said 1 board is working, so, have you checked complete reads,writes and initialization with this. So,that we can take this configurations(all registers and other stuff) as reference.
In Non-Working board,
I assume powers are OK within specifications (mainly Vref to both DDR2 and controller)
Can u check CKE# to go HIGH and CK/CK# is running, during interface initialization as per Jedec spec.

In JESD79-2F page 27, there is a initialization procedure,
mostly programming EMR registers require either of BA(bank address inputs) toggling, or A10 toggling..

Check whether A10 or any Bank address signals are toggling or not?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If we are confident that assembly is not an issue...then it's OK....
Otherwise please check impedance's of rails VDD,VREF and important lines like DQS,any of DQ, any of address lines to see internal shorts.....
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Click to expand...

Hello again

I appreciate your great help!

I need to say that this is not my first DDR2 design and we have made over 1000 working units with my earlier design. It is however the forst design that is having this trouble during prototype stage and that is why I am worried.

I am sure the initialisation sequence from CPUI side is ok as we have used it many times.
I am not sure that the DDR2 RAM is receiving this correctly because there could be some issue with lines or maybe impedance or reflection.

Impedance is routed for 50Ohm and track lengths are matched to better than 0.1". All tracks are shorter than 2.1" (52mm)

CK/CK# looks ok at 133MHz measured on series termination resistor.

Yesterday I sent the board to the manufacturer to get the DDR2 chips replaced.
When it returns on Monday or Tuesday, I will let you know and we can discuss it further.

Regards
X

You are very experienced than me in this scenario. But as i don't know what's happened.....I asked many details...Don't think otherwise....

"I am not sure that the DDR2 RAM is receiving this correctly because there could be some issue with lines or maybe impedance or reflection."
As for both prototypes same PCB and routing, I don't think there is any issue with receiving. Reflections may not possible, but you don't have much loading and routing length is less....

Finding assembly problems is very difficult.
I am not saying about trace impedances, if you check pin(DQ,DQS,ADDRESS) impedances if you find any low impedance then there can be possible short.

It is hard to tell without any pictures, but you might be getting excessive ringing or noise or marginal setup time violations that would be hard to accurately measure/see with your scope. I'd consider a 300 MHz front end on the scope to be marginal when trying to accurately debug 266MHz digital signals - do you have >300 MHz probes or active FET probe available? I'd try to use 500MHz tools on this if possible for looking at possible timing or noise/ringing/reflection issues

Hi ....

whether boards came back...what is the present status....