This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3358: DDR3L - CE stays low while CK Runs

Part Number: AM3358

Tool/software:

I have a breakout board that I’m using in between the BBB and its DDR3L chip. I’ve verified that the memory chip functions properly without the breakout board, but once the board is attached, I get some really weird behavior on the memory traces during memory initialization.

So here’s how the RAM init process should start.

But check this out: We can see #1 from the above process, where CE (blue) goes low. After 700 ms or so, the CK (yellow) starts running. No idea why, but CE is still low during that time. But see that jitter on the CE line right as the CK starts? Yet It’s only right after the CK stops that CE goes high again…

I considered that this jittering could come from cross-talk on the interposer… I’m having a hard time getting the cross-talk “calculator” in AD to behave. But an online calculator says that the cross-talk between the CK and CE lines due to the breakout board should be negligent, on the order of 2 or 3 mV… And that jitter seems to be more than that. Perhaps this could be a by-product of cross-talk and supply-voltage fluctuations in the ASIC itself, which TI deemed an acceptable amount. But we don’t know that.

However, there is a part of me that wonders if perhaps the SoC has trouble driving both the CK and CE lines together without termination resistors - because while they do help with SI, they also should help with drive. I didn’t think drive-strength variations were possible in DDR3, but what about a drive issues overall?

Weirdly enough, after the CK stops and the CE goes high again, the SoC procedes to communicate with the RAM like the RAM’s actually listening or something…

See here the CK (yellow) and the DMU (blue).

And here the CK (yellow) and an ADDR trace (blue).

CE stays high during all of this, but CK doens’t run, although you can see it jitter a bit in the sections where the second sampled trace (blue) gets pulled up and down.

Interestingly enough - you know how sometimes during a failed boot process, the LEDs sometimes count up and down, even minutes after initially powering the board on? When those LEDs change like that, the SoC memory controller seems to want to try doing something, presumably re-initializing. See the CK (yellow) and DMU (blue).

I’m trying to figure out what’s going on. Why does CE stay pulled low when CK is pulled high? It’s like the SoC thinks the CK and CE are both functioning properly, then gets weird when it can’t finish init?

The primary purpose of the termination resistors is prevent reflections and ringing. They’re not really supposed to do that much in terms of drive, but at the same time, the SoC n’t wasn’t designed to be the absolute best possible chip ever. It was designed to be cheap. TI has a document detailing errors they made in the silicon itself, so I’ll check into that today and see if there’s anything noteworthy there. The trm notes that one particular memory function has to be implemented in software because of a silicon error, but iirc, it was rather obscure and didn’t seem to pertain to what we were doing… Thinking

Does anyone have any thoughts or suggestions about this?

  • Micron documentation sorta-kinda implies that the clock will be running before CE goes high... but it also says it should stay running while the NOP command is being run.

     

  • Andrew, the processor will go through the initialization sequence as outline in the Micron datasheet that you show.  RESET and CKE will go low for a period of time, then RESET will go high followed by CKE after 500us.  Then the processor will initialize the DRAM with appropriate register writes, ZQ calibration, etc.  The clock should be present throughout this portion of the init and beyond.  It should never go quiet.

    What kind of resolution do you have on your scope?   I think you are trying to capture way too much data and the scope doesn't have enough resolution, so your signals look weird.  I would zoom in to see if you can see a consistent and stable clock.  You should be using active probes, otherwise you will be affecting the signal you are probing.

    Just curious, what is your goal with the interposer?  Are you performing analysis or trying to debug an issue?

    Regards,

    James

  • Unfortunately, we're very budget-constrained and limited to a 1 Gs/sec (used for the screenshots) and a 5 Gs/sec scope, both with passive probes. The screenshots above were from the 1 Gs/sec. While there would of course be aliasing, I was mainly wanting to verify that there appeared to be signals on those lines, as well as the relative timing between them viewed at a sufficiently large time delta.

    This board is part of a larger proof-of-concept project for a real-time memory watchdog system.

    I'm thinking the scope should be fast enough to catch a clock signal, even though it isn't quite adequate for a clean signal...

    Some interesting data I grabbed last Friday. Positive clock yellow, reset blue. The logic levels on the clock are quantitatively different. Not sure if maybe one is for the SSTL 1.5 V of DDR3 and the other is the SSTL 1.35 V for DDR3L. It's not depicted, but CKE is going high right about when the CK stops. Hopefully, I can get a zoomed in version soon.

    Here's the very first memory initialization after power-on.

    Here's the same waveforms after hitting the board's soft reset button.

  • Andrew, tough to tell what is going on with those scope shots.  Can you tell what frequency you have on the clock?  You may want to make some initial measurements on the EVM without the interposer (maybe scrape down to a via on the clock signal) to see what you should expect.  You could be loading the clock signal too much with the passive probe.

    Regards,

    James