In comp.arch.embedded,
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

[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.
		-- Henry Adams

In comp.arch.embedded,
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>In comp.arch.embedded,
>Karl Olsen <kro@nospam.post3.tele.dk> wrote:
>>In news:81548$4354fbb0$54f63171$17603@publishnet.news-service.com,
>>Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> typed:
>
>>> 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;
>>>
>>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.
>>
>Reasonably sure, I verified with a scope that A5 is high during the load
>mode register command. But I will check this again.
>
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:
	A portion of a book, for which nobody yet has discovered any use.

In comp.arch.embedded,
KenHopkins <k.hopkins@btinternet.com> wrote:
>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 ?
>
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.

>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
>
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."
-- George Bernard Shaw

In comp.arch.embedded,
Karl Olsen <kro@nospam.post3.tele.dk> wrote:
>In news:81548$4354fbb0$54f63171$17603@publishnet.news-service.com,
>Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> typed:

>> 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;
>>
>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.
>
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.

>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.
>
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:
	Filing almost everything under "the".

In comp.arch.embedded,
Frieder Ferlemann <F.Ferlemann@identecsolutions.de> wrote:
>Stef wrote:
>> 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
>
>Actually you might be better off with smaller capacitors.
>Check the impedance over frequency characteristics of the
>capacitors you are using.
>
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 
the left.

Stef wrote:
> 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

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

Greetings,
Frieder

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
www.claymore-electronic.co.uk

In news:81548$4354fbb0$54f63171$17603@publishnet.news-service.com,
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> typed:
> 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?

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

In comp.arch.embedded,
linnix <me@linnix.info-for.us> wrote:
>
>Stef wrote:
>> 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:
>>...
>> 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.
>
>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.
>
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.
		-- Lyle Alzado, professional football lineman