SDRAM data garbled due to seperate PCB for SDRAM ???

Hi,

Im trying to interface two 128Mbit SDRAMs (MT48LC8M16A2) to the AT91RM9200, but it doesnt seem to be going right. I have a custom board for the AT91, and a seperate board for the SDRAM, the two are connected through an ordinary ribbon cable.

The master clock of the uC is running at 60Mhz. To test the integrity of the RAM, im writing data to a series of locations, say from

0x2000_0000 to 0x2000_0100. But when i read the data back, i find it to be garbled at *many* locations. I mean, instead of 0x11111111 that im writing, i get a 0xEff1111 or something at some locations, while on others the data is perfect. (im sending data out from the debug unit to HyperTerminal for debugging)

I have tried all permutations and combinations of the initialization sequence, but to no avail. Even tried changing both the ribbon cables (ive got one for the address lines, another for the data). What could be going wrong?? I dont think any of the SDRAMs has gone bad, because they both seem to have the correct data sometimes.

COuld it be because of the fact that im using a seperate PCB for the RAM chips??

Thanx in anticipation Mayank

Reply to
Mayank Kaushik
Loading thread data ...

How long are the ribbon cables? Do alternate signal and ground wires? How well are the RAM supplies decoupled?

Peter

Reply to
Peter Dickerson

How long? er..approx 25-40cms.

I didnt understand that..

Both the SDRAM chips are on the same PCB, one on either face. They both get their supply from the same source...im not sure since i didnt build the board myself, but i think their supply lines are tied together and come from the same main line.

Thanx Mayank

Reply to
Mayank Kaushik

Very long!

Is the cable wired like this: pin1 - signal1 pin2 - signal2 pin3 - signal3 pin4 - signal4 (...)

or like this:

pin1 - signal1 pin2 - GND pin3 - signal2 pin4 - GND (...)

both

This isn't what he was asking. Are there decoupling capacitors on the SDRAM PCB? Are there separate decoupling caps for each pair of Vcc/Vss pins on each chip? Have you inspected the power rails at the chip pins with an oscilloscope, referenced to local ground on the PCB and also referenced to ground on the main CPU board?

Reply to
larwe

Hi!

Thats the way its wired..bad, huh?

Vcc/Vss

pins

Er..Nahin,Nope respectively :-( I did inspect the pins on the SDRAM that are fed Vdd and Vss with a multimeter, the level was correct..do u mean the measurement of the capacitance between them..i dont have any experience with these things, some enlightenment would be welcome, im still an undergrad.

One question..how is the Hard Drive of a PC able to get by with its equally long IDE cable??

Regards Mayank

Reply to
Mayank Kaushik

They are designed for use with long cables and use special line-driver circuits. SDRAMs are designed to be placed on-board. Also for the high- speed IDE versions you are required to use a special 80-conductor IDE cable, which puts an extra ground wire between every signal line.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

When you get your PH.D. will you get able to work at BURGER KING?
Reply to
Stef

For starters: that cable (at least originally), carries only ISA bus type signals, whose clock speed is only about 8 MHz, or 125 nanoseconds.

Second, a counter-question: why, do you think, did the specification of the ATAPI cable have to change, as of the "UDMA" generation, to now

80 wires (twice the original)?
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Redo from start.

I think you'll never get it to work that way. Redesign it with the SDRAM on the same board. If *must* try to get it to work, look for reflections on the control signals and try to dampen them out with series resistors.

Reply to
Jim Stewart

now

errr..ummm...ah..they put in xtra (ground?) cables to take care of the currents that would be induced in the neighbouring cables due to the signals that change at a high speed (to provide a return path for the currents??) ???

Regards, Mayank

Reply to
Mayank Kaushik

nice VHF Transmitter you got there :) start with replacing this cable with UDMA60/100/133 HDD IDE cable wiring as larwe suggested

solder decoupling capacitors directly to ram pins

Pozdrawiam.

--
RusH   //
 http://randki.o2.pl/profil.php?id_r=352019
 Click to see the full signature
Reply to
RusH

And you may still have issues if the ARM part isn't designed to drive that long of a line -- the MPC860, for one, gave you a choice between drivers or putting the SDRAM right next to the chip -- a driverless schematic with long traces or a cable was definitely not in the cards.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

Hi everyone,

If the SDRAM chips are on the same board as the CPU, will there still be a need for decoupling caps on the SDRAM`s power supplies? Regards Mayank

Reply to
Mayank Kaushik

Yes.

--Gene

Reply to
Gene S. Berkowitz

Now _this_ calls for a story:

In my misspent youth I worked my way to an MS degree as a teaching assistant. One semester I was in charge of the lab for 4th-year analog circuit design (i.e. how to make an op-amp out of two sets of matched transistors, some resistors and a capacitor).

As we came to the point where everyone's circuit was going together I had occasion to go around the lab making people put in decoupling caps. One intrepid pair insisted that there was no reason for them, their use was black magic, and would I please tell them why their circuit was oscillating? I told them that it was good to humor crazy people, and I wouldn't help them until I saw the caps. I came back later to find the caps in place, and their circuit happily working.

_Always_ put in decoupling caps. Every IC on the board should have at least one decoupling cap. Multiple power pins are the IC designer's way of telling you the chip needs multiple decoupling caps.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

Looks like you've had some good replies so far. It also looks like you have quite a bit to learn about high-speed logic design.

Briefly: look into "transmission lines". A track (or cable) acts as a transmission line at high frequencies (it has series inductance and parallel capacitance). If you don't terminate the track correctly at either end, you'll get reflections - meaning that your nice square edges end up looking very messy. It's quite common to need to take this into account when bus signals are on the same board, let alone on different boards connected by ribbon cables.

Re decoupling: this is fairly fundamental stuff ;). Again, consider that the power tracks/cables are not perfect. On a change of output, there is a brief spike of current - needed to inject charge into the track. Decoupling capacitors ensure this current is delivered locally, rather than via the inductance of the power track - which would cause a brief dip in the applied power, probably also affecting plenty of other devices in the neighbourhood.

As I said, this was brief ;).

HTH,

Steve

formatting link

Reply to
Steve at fivetrees

Also those signals take perceptible time to travel down those lines. You can normally make a guesstimate of 1 nS per foot (3 nS per meter) for one way travel, and be reasonably close. So you can see that even if you have infinitely fast memory at the other end of a meter of cable, you can't expect to get an answer back in less than 6 nS. That has already put a cycling repetition limit of about 160 Mhz on the system. In practice the transaction time will be much greater, and cycling repetition rate much slower.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 Click to see the full signature
Reply to
CBFalconer

Hello everyone,

Thanx for all your replies.

CBFalc>Also those signals take perceptible time to travel down those lines

In accordance with that, i had pared the cable down from 35-45cms initially to about 15cms, yet i saw no change in the garbled data. Maybe other factors are having a greater effect.

The decoupl>If you don't terminate the track correctly at either end,

looking

Lending credence to the impedence mismatch theory at the cable ends is the fact that when i try to read the same data a number of times, i get different values sometimes..perfectly correct sometimes, semi-garbled sometimes..Would it help to solder the cable ends to the board pins (not the ram pins)?

parallel

took a course in transmission lines last semester...until now, never thought it would ever come in handy ;-)

Best regards Mayank

Reply to
Mayank Kaushik

A few random thoughts...

Have you tried a *much* slower cycle on your signals, plus adding delays between each step (command + clock strobe + MCU input) to let the line stabilize? This SDR chip should tolerate a very slow clock cycle (although "stable" is a requirement).

Have you checked with a scope to see if the input rise times are within spec at the SDRAM?

Are you certain you've got the CS lines right so only one chip is selected during an operation, so they don't conflict?

Once you get past the signal and power issues, try posting code snippets for the init, I/O, and refresh (you are refreshing, right?)

Reply to
Richard H.

delays

line

I thought of that. I need the 60Mhz cycle, coz im using the DBGU (debug unit) on the chip as my sole debugging aid. It needs a bit-rate of

115200bps, for which i need the 60Mhz master clock. I could bring it down to 1Mhz, i think...il try that. In the USART, each bit would be sent out at at least one clock edge, and for receiving, the rate should be double the bit rate..so that puts a cap on the lowest i can go...but i wonder..hmmm.il check that.

within

To Do.

Actually both chips are supposed to be selected at a time, the CS lines are tied. Each byte is taken care of by masking lines on the chip. Yes, i have checked them.

snippets

Yes, of course :-). This AT91RM9200 has an SDRAM controller that takes care of all the refreshes after you feed in the proper refresh times. ============================== Heres the code for that: (im using Atmel`s libraries)

int i; int *pSDRAM = (int *)BASE_EBI_CS1_ADDRESS;

//* Configure PIOC as peripheral (D16/D31) AT91F_SDRC_CfgPIO();

//* Setup MEMC to support CS1=SDRAM AT91C_BASE_EBI->EBI_CSA |= AT91C_EBI_CS1A; AT91C_BASE_EBI->EBI_CFGR = 0;

//* Init SDRAM

AT91C_BASE_SDRC->SDRC_CR =

0x01 |//NC=9 columns 0x04 |//NR=12 rows 0x08 |//NB=4 banks 0x40 |//CAS=4 0x100 |//TWR=2 0x2800 |//TRC=5 0x10000 |//TRP=2 0x180000 |//TRCD=3 0x2800000 |//TRAS=5 0x28000000 //TXSR=5 ;

//* 2. A Precharge All command is issued to the SDRAM AT91C_BASE_SDRC->SDRC_MR = AT91C_SDRC_MODE_PRCGALL_CMD;

*pSDRAM = 0;

//* 3. Eight Auto-refresh are provided AT91C_BASE_SDRC->SDRC_MR = AT91C_SDRC_MODE_RFSH_CMD; for(i=0;iSDRC_MR = AT91C_SDRC_MODE_LMR_CMD;

*(pSDRAM+0x80) = 0;

//4.5 Three NOPs to take care of tMRD AT91C_BASE_SDRC->SDRC_MR = AT91C_SDRC_MODE_NOP_CMD; for(i=0; iSDRC_MR = 0x0;

*pSDRAM = 0;

//* 5. Write refresh rate into SDRAMC refresh timer COUNT register AT91C_BASE_SDRC->SDRC_TR = (AT91C_SDRC_COUNT & 0x2E0);//4096 refresh cycles every 64ms

*pSDRAM = 0; ======================================

Regards Mayank

Reply to
Mayank Kaushik

"Mayank Kaushik" schrieb im Newsbeitrag news: snipped-for-privacy@z14g2000cwz.googlegroups.com...

Also check the clock signal for undershoot/overshoot or possible double clocking (clock rising above halve value, then descending due to reflection and rising again to full value).

You need a good (FET) probe and a high bandwidth scope to see this effect in action.

- Rene

Reply to
Rene

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.