Re: Instability during access to off-chip memory when cache enabled

David Brown <[email protected]>
Newsgroups gmane.comp.hardware.motorola.microcontrollers.coldfire
Organization WestControl a.s
Message-ID <[email protected]>
X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information 
X-SpamDetect: ****: 4.000000 GreyPassed=1.0, DodgySource=2.0, SPF Default Fail=1.0
X-SpamDetect-Info: ------------- End ASpam results -----------------

I'm posting this as a reply to an old thread, since I finally figured 
out what my problem was - perhaps the information here will be of help 
to others either now, or in the future when searching the mailing list 
archives.

I was having a problem with my MCF5234 card with two 16 MB sdram chips 
(MT48LC4M32B2).  The sdram chips worked fine when the MCF5234's cache 
was disabled, but obviously the chip is then pretty slow (the chip's 
sdram controller is horribly slow, as it does not track open rows).  The 
problem was that when I enabled cached access to the sdram area, I had 
incorrect operation - burst reads were incorrect if address line A19 was 
high, but correct if A19 was low.  I'd eliminated possible timing or 
signal problems (the results were consistent across boards, and at 
different clock speeds).

I finally traced the problem to the CBM setting in the DACRn registers 
(Table 18-5, page 346 of Rev. 2 of the MCF5235 Reference Manual).  The 
table in the documentation shows that when address lines A22 and up are 
connected to the bank select bits of the sdram (as they are in my 
design), CBM should be set to 4.  It turns out that it is the command 
bit that is the critical point, and on the ram chip I'm using, this is 
connected to A20 (the sdram's A10 pin), so CBM should be 3.  The sdram 
controller then believes the sdram has 8 banks instead of 4 - but since 
it does not track banks, this makes no difference.

So if anyone else is having trouble with sdram devices with a ColdFire, 
I'd recommend re-reading the documentation to see if there are other 
ways to interpret the tables.

And if anyone from Freescale is reading this, it would be *extremely* 
useful to have an application note with connection examples and register 
setups for a dozen or so common sdram types and different ColdFire 
devices.  The documentation in the MCF5235 manual is far from clear - 
Table 18-7 "Generic Address Multiplexing Scheme" is utterly 
incomprehensible, and the single example given is ridiculous (I'm sure 
whoever wrote it had a good reason for specifically only accessing half 
of their sdram, but I can't think what it might be).

mvh.,

David

---
[email protected]              Send a post to the list.
[email protected]        Join the list.
[email protected]    Join the list in digest mode.
[email protected]     Leave the list.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.