AT91RM9200 and 16-bit SDRAM not working

Hello All,

I am trying to get a 16-bit SDRAM (MT48LC16M16A2-75) to work with the AT91RM9200 and no matter what I try, it fails to work properly:

Hardware connections: AT91RM9200 MT48LC16M16A2

---------- ------------- D0-15 DQ0-15 A2-A11 A0-A9 SDA10 A10 A13-A14 A11-A12 BA0/1 BA0/1 SDCKE CKE SDCK CLK \BS0/1 DQML/H \RAS \RAS \CAS \CAS \SDWE \WE \SDCS \CS

Init code: volatile int *pRegister;

pRegister = (int *)0xFFFFFF98; // SDRAMC_CR *pRegister = 0x2188C159;

pRegister = (int *)0xFFFFFF90; // SDRAMC_MR *pRegister = 0x00000012; // 16-bit, precharge all on access pRegister = (int *)0x20000000; *pRegister = 0; pRegister = (int *)0xFFFFFF90; // SDRAMC_MR *pRegister = 0x00000014; // 16-bit, refresh on access pRegister = (int *)0x20000000; // MT48LC16M16A2TG-75 requires 2 refreshes *pRegister = 0; // But do 8 like all examples *pRegister = 0; *pRegister = 0; *pRegister = 0; *pRegister = 0; *pRegister = 0; *pRegister = 0; *pRegister = 0; pRegister = (int *)0xFFFFFF90; // SDRAMC_MR *pRegister = 0x00000013; // 16-bit, Load mode register on access pRegister = (int *)0x20000040; // Address will go in mode reg. mode must be

0x020 *pRegister = 0;

pRegister = (int *)0xFFFFFF90; // SDRAMC_MR *pRegister = 0x00000010; // 16-bit, normal mode on access pRegister = (int *)0x20000000; *pRegister = 0;

pRegister = (int *)0xFFFFFF94; // SDRAMC_TR *pRegister = 0x000002E0; pRegister = (int *)0x20000000; *pRegister = 0;

I've played around with the value of SDRAM_CR, the number of refreshes and the addres vor the mode register set, but no change. After this init procedure, I see refresh cycles every 15 us.

When I write the entire SDRAM with 0x0001 and then read back, all I get is

0xFFFF. When I write and immediately read the same location, I mostly get the right value back, but in about 1 out of 2000 (seems random) I get 0xFFFF instead of the right value (0x0001). And the wrong value is always 0xFFFF, nothing else.

Any ideas what to try next?

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

You're definitely on their list.  The question to ask next is what list it is.
Reply to
Stef
Loading thread data ...

Sound like noise or unmatched impedance on the signal/data lines. SDRAM layouts are very tricky. If you don't have enough shielding and impedance matching, you are looking for troubles.

Get someone to review your layouts.

Reply to
linnix

For this part you should generate an auto refresh every 7.81us on average. You could also try setting the cas latency to 3 or 4. Another trick is to slow down the SDRAM interface to a much slower clock rate. Finally, SDRAM designs need a good understanding of the memory controller settings as well as the hardware and layout.

Ken

formatting link

Reply to
KenHopkins

I have solid power planes (ground and 3V3) on the entire board and every power pin of the SDRAM is bypassed with a 100nF capacitor. So I'm OK on the shielding part. The SDRAM is very close to the CPU and the data/address bus to the rest of the board is separated by means of buffers. Total trace length between CPU, SDRAM and buffer is small, but no special care is taken to match the lines. The problem remains the same if I reduce the clock rate to 36MHz. If the problem is with the signal matching, I would expect more random values and not correct OR 0xFFFF, wouldn't you?

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

I never met a man I didn't want to fight.
 Click to see the full signature
Reply to
Stef

You are right on the refresh, but unfortunately reducing the time between auto refreshes to 7us does not change the behaviour.

The AT91RM9200 SDRAM controller only allows a CAS latency setting of 2.

I have reduced the clock from 72MHz to 36MHz, no effect. Should I try to go down even further?

I did find an error in my initialization: I was doing 32-bit accesses in the init phase instead of 16-bit. But aparently the SDRAM controller already ignored this during init as there is no visible change on the generated waveforms.

Although the layout may not be optimal (lines are short but not matched, full power planes, all power pins bypassed with 100nF), I think it is my understanding of the settings that is the problem. Any pointers?

I just discovered that the SDRAM's data outputs remain Hi-Z during a read cycle and all I'm reading back is the pulled up bus. Pulling a line down with a resistor changes the read-out value. What may cause this behaviour and how should a read cycle normally look?

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

"You're just the sort of person I imagined marrying, when I was little...
 Click to see the full signature
Reply to
Stef

Are you sure you load the mode register correctly? In my AT91RM9200 with

32-bit SDRAM, I want to load the SDRAM mode register with 0x0020, and since CPU A2-11 --> SDRAM A0-9, I use address 0x0080 on the CPU pins. It works.

And are you sure you shouldn't use CPU A1-10 --> SDRAM A0-9 with your 16-bit SDRAM? The datasheet isn't clear -- figure 13-2 suggests A0-9 --> A0-9 for

32-bit SDRAM which is definitely wrong.

Karl Olsen

Reply to
Karl Olsen

At 36Mhz I would think that cas latency of 2 should be OK. If you have a scope or logic analyzer it may be time to use them. Are you generating chip select, RAS, CAS and Address synchronous to the clock. If the data lines are tri-state during a read then are you generating the read cycle correctly ? What about series terminations ? Are the DRAM and chip on the same power rail ? Have you tried more than one board ?

If you check the Micron datasheet for your part you should be able to see what read cycles look like. All signal are valid on the rising edge of the clock

Ken

formatting link

Reply to
KenHopkins

Actually you might be better off with smaller capacitors. Check the impedance over frequency characteristics of the capacitors you are using.

Greetings, Frieder

Reply to
Frieder Ferlemann

I have a 2+16 HP scope, it's already connected to some lines, I will connect the others.

CPU and SDRAM are on the same power rail. No series termination. The schematics are somewhat based on the AT91RM9200's eval board which has no termination either. I have tested only 1 board up to now but have tested on another board in the past. This board is of simular design and had the SDRAM stuck on as a "bonus". Unfortunately we where not allowed to get to the root of the problem there before designing this board. But as the problems look very simular I am still betting on software probles rather than hardware problems for now.

Yes they are in there, but which one? I find these SDRAM datasheets a bit difficult to read as I have only used SRAM in the past, but I'll get used to it I suppose.

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

"Success covers a multitude of blunders."
 Click to see the full signature
Reply to
Stef

Reasonably sure, I verified with a scope that A5 is high during the load mode register command. But I will check this again.

In 16-bit mode, the Column/Row lines of the SDRAM controller are connected differently to the CPU core address lines than when in 32-bit mode. So I had to shift 0x80 one bit to the right.

It indeed is confusing, here's how I read the datasheet: The chapter on the EBI shows the SDRAM controller lines A0-A9 are mapped to EBI (is external) pins A2-A11, not depending on the buswidth.

The chapter on the SDRAM controller says how the cpu core lines are mapped to row/column, depending on buswidth. The SDRAM controller will output the row or column on _it's_ lines A0-A9 (and the rest of them), which are the external pins A2-A12.

In my opinion your figure 13-2 (in doc1768.pdf they are called figure 87 and

88) is not wrong, but you have to remember it shows SDRAM controller A0-A9, not EBI pins.
--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Secretary's Revenge:
 Click to see the full signature
Reply to
Stef

That might be true, but unfortunately I can not find this information in the datasheet. I'm using samsung X7R 50V 0805 MLCC caps (CL21B104KBNC).

At the moment however, lowering the frequency does not seem to change a thing and I am therefore now focussing on software problems, but I'll keep your suggestion in mind. If you look at the AT91RM9200 eval kit schematics, you'll find they also use 100nF caps.

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

The first sign of maturity is the discovery that the volume knob also turns to 
 Click to see the full signature
Reply to
Stef

This is geting weird: I've tried different values and 0x20000010 lets A5 (SDRAM, A7 CPU) low as expected. but ..20, ..40 and ..80 all put A5 high and A4/A6 low (other address lines not connected to analyzer).

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

Appendix:
 Click to see the full signature
Reply to
Stef
[SDRAM problem]

Well the problem is solved! 32MB of SDRAM running happily at 73MHz.

It was, as always, a very silly mistake: The pin numbers of RAS and CAS on the SDRAM's schematic symbol where swapped. An error me and a collegue have overlooked several times. :-(((

The strangeness of A4=0,A5=1,A6=0 whether i write 0x020, 0x040 or 0x080 to the mode register remains. Maybe it's Atmel's way of enforcing a CAS latency of 2 (the only value supported by the AT91RM9200)?

Now I still have a problem getting PLLA to work, but that's a different thread. ;-)

Thank you all for thinking with me, it helped!

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

Practical politics consists in ignoring facts.
 Click to see the full signature
Reply to
Stef

For which you and a colleague should get shot several times !

-- Cecil

Reply to
Cecil Hill

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.