Electronic – What are these pull ups for on this SDRAM

memorymicrocontrollersdram

Apologies for all these questions about SDRAM, but I want to get this next board run right.

I have an LPC1788 processor with an external memory controller I am interfacing with SDRAM. There is no reference design in the user manual of the microcontroller, but I have a development kit I am using as a reference.

For some reason they have pull ups (not termination resistors) on signals such as CLK, CLKE, DQM0-3. Why is this? I was under the impression the microcontroller has internal pull ups for this sort of thing? Are they necessary, or just there out of good practice (is that the same thing)? Should these be places at the source or sink?

Also, what is the capacitor on the CLK line for? Will this not disturb the signal?

enter image description here

I have implemented the termination resistor packs in my own design (currently at 22Ohms although I understand it depends upon the trace impedance).

Many thanks.

Best Answer

The 33k pullup/down resistors are to make sure the signal is at a valid logic level when those signals are not being actively driven. With some CPU's this can happen at startup, especally if those CPU pins must be configured before they work as an SRAM interface.

They do nothing that a normal "termination resistor" does, as the resistance is way too high. For a termination resistor to work it must be the same value (or thevenin equivalent) as the trace impedance. There is, to my knowledge, no way to make a trace impedance of 33K ohms. Although I could be wrong, I don't think you can make a trace with an impedance higher than the impedance of free space which is about 377 ohms. You will rarely see termination resistors larger than this (or the thevenin equivalent).

The cap on the clock line is a HACK, and I suspect that it's not actually installed on the PCB. Some people do this to compensate for a badly terminated signal or to actually tweak the timing of that signal. IMHO, this is stupid and a properly designed system should never need this kind of kludge. Of course, sometimes the stupidness is inside the chip and you have no alternative but to use something like this.

I am concerned that some of the comments on the question talk about termination resistors in terms that are not even close to correct. (Sorry @JustJeff, it's not personal.) Lack of proper termination causes overshoot, undershoot, ringing, and unwanted reflections. Proper termination does not dampen these things, instead it stops it from happening in the first place. Termination actually prevents the conditions from forming that cause bad signal integrity, not trying to band-aid it later by dampening the bad stuff.

The problem with "dampening" is that there is no distinction between dampening the bad stuff and dampening the signal itself. With proper termination you can get rid of the bad stuff without making the signal itself suffer! Learning exactly what trace impedance is, and how termination can deal with the effects of that, is super important for professional designs and is very useful for the hobbyist. It's beyond the scope of this answer, but suffice it to say that everybody needs to study up! :)

Related Solutions

Electronic – Editable PIC Serial Number in HEX File

Specifically to resolve the question of binding variables to specific addresses in flash memory on the PIC18 with the C18 compiler, please reference the section "Pragmas" in the hlpC18ug.chm in the doc directory where the compiler is installed.

To do this you need to define a new "section" in memory and bind it to a start address so

#pragma romdata serial_no_section=0x1700

This creates a new section called "serial_no_section" that starts at address 0x1700 in flash (program) memory (because we defined "romdata" in the #pragma).

Directly after the #pragma line, define your variable(s) so:

#pragma romdata serial_no_section=0x1700
const rom int mySerialNumber = 0x1234;
#pragma romdata

Now you have 0x12 at address 0x1700 and 0x34 at address 0x1701 in memory (because PIC18 uses the little-endian model). The "const rom" ensure that the compiler knows that this is a const variable type, and that the variable lies in "rom" memory and thus need to be accessed via table read instructions.

The final #pragma romdata statement ensures that any following variable declarations are linked to default memory sections as the linker sees fits rather than following on in the "serial_no_section" section.

Now all code can simply reference the variable "mySerialNumber", and you know exactly what address the serial number can be found at in memory.

Editing the HEX code can be a bit challenging as you need to calculate the checksum for each line you edit. I am working on a C++ class to decode and encode Intel HEX files which should make this easier, but it is not finished yet. Decoding files works, encoding again is not yet implemented. The project (if you are interested) is here https://github.com/codinghead/Intel-HEX-Class

Hope this helps

Electronic – SDRAM issue – LPC1788

Long, parallel traces. No signal termination. No decoupling caps on the RAM. Signal traces going from top to bottom layer without a cap near by. Traces with long, unterminated, stubs. Some signals going through 5 vias. And possibly not enough vias on the power/gnd pins of the BGA (but it's hard to tell from your picture).

Any of these could cause memory problems, and some at any speed. Carefully probe your clocks at the destination with a high speed o-scope (350 MHz or greater) and show us what you see. Odds are that you have a problem with signal integrity.

Best Answer

Related Solutions

Electronic – Editable PIC Serial Number in HEX File

Electronic – SDRAM issue – LPC1788

Related Topic