topic Re: 68000/coldfire difference in ColdFire/68K Microcontrollers and Processors

68000/coldfire difference

Dietrich — Sat, 01 Apr 2006 07:44:53 GMT

This message contains an entire topic ported from the WildRice - Coldfire forum. Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions. Freescale assumes no responsibility whatsoever with respect to Posted Material. For additional information, please see the Terms of Use - Message Boards and Community Forums. Thank You and Enjoy the Forum!

Aug 24, 2005, 4:48 AM

Post #1 of 17 (276 views)
Copy Shortcut
[ColdFire] 68000/coldfire difference Can't Post

--------------------------------------------------------------------------------

right now i implement a 68k system. 68ec000, 128kbyte flash, 256kbyte ram.
this includes to write an assembler. it is more than 50 percent complete.

now, the 68000 is microcode based (the chip contains a microcode table).

can someone list up the difference between 68000/coldfire (in a few lines)?

additionally, i plan to write assemblers for the SH2 (hitachi), and probably even for the pentium. the implementation is in BASIC, and highly relies on tables. additionally, a native version (which can translate itself) is planned for the 68000 board.

the purpose is to write a few demos for the SEGA MEGA DRIVE.

recently i soldered in a PLCC version of the 68ec000, including bending all the pins into flatpack style. for real flatpack, they are too small for manual soldering.

programming web space
http://spaces.msn.com/members/afinn23console

Aug 24, 2005, 6:00 AM

Post #2 of 17 (275 views)
Copy Shortcut
Re: [ColdFire] 68000/coldfire difference [In reply to] Can't Post

--------------------------------------------------------------------------------

The Coldfire has almost the same programming model as the 68k. There are a
few extra instructions (especially for cores with extra functionality, like
a MAC unit), and it is missing some of the more obtuse addressing modes from
later 68k chips. Otherwise, the real difference between the cores is that
the Coldfire is far more efficient. There are, of course, huge differences
between individual Coldfire chips and a 68000 chip - the ColdFire series are
microcontrollers with lots of built-in peripherals, rather than just a plain
cpu. You'd want to look at the Freescale web site to get summaries of the
different Coldfire micros.

I can't imagine why anyone would write an assembler for the 68000, or the
Coldfire for that matter, unless it is as a learning experiance. There are
many assemblers available, including the excellent open source gnu assembler
(which can be cross-compiled to run on a 68k machine if you want). Most
people would use C or another high-level language, however - again there is
a huge range of tools available.

By the way, it's normal to use a capital letter at the start of sentences in
English - Latin is out of fashion these days.

mvh.,

David

----- Original Message -----
From: Alex Finn
To:

Sent: Wednesday, August 24, 2005 1:48 PM
Subject: [ColdFire] 68000/coldfire difference

right now i implement a 68k system. 68ec000, 128kbyte flash, 256kbyte ram.
this includes to write an assembler. it is more than 50 percent complete.

now, the 68000 is microcode based (the chip contains a microcode table).

can someone list up the difference between 68000/coldfire (in a few lines)?

additionally, i plan to write assemblers for the SH2 (hitachi), and probably
even for the pentium. the implementation is in BASIC, and highly relies on
tables. additionally, a native version (which can translate itself) is
planned for the 68000 board.

the purpose is to write a few demos for the SEGA MEGA DRIVE.

recently i soldered in a PLCC version of the 68ec000, including bending all
the pins into flatpack style. for real flatpack, they are too small for
manual soldering.

programming web space
http://spaces.msn.com/members/afinn23console

--------------------------------------------------------------------

Aug 24, 2005, 6:09 AM

Post #3 of 17 (275 views)
Copy Shortcut
Re: [ColdFire] 68000/coldfire difference [In reply to] Can't Post

--------------------------------------------------------------------------------

thanks for your reply.

about the suggestion to check the freescale site, i did that today.

indeed writing the 68000 assembler prodcued better understanding, now i tend to integrate "microcode tables" into all of my programs.

another issue: the documentation of the sega master system/mega drive are not official releases. the native version allows to write programs on the mega drive itself, and i plan to include a rudimentary programming documentation into the system.

by the way there is a plug'n'play TV set (on the current market), which (i guess) includes a 68000 core. probably it can take any MEGA DRIVE software, however, it does not have a module port.

people notice everything small. however, it is legal latin spelling, and hints for capitalization are hard to find sometimes.

alex.

---------------------------------

Aug 24, 2005, 6:12 AM

Post #4 of 17 (275 views)
Copy Shortcut
Re: [ColdFire] 68000/coldfire difference [In reply to] Can't Post

--------------------------------------------------------------------------------

hi,
see my web .......... i think there we could collaborate

tell me about your 68ec000 system

http://www.webalice.it/devilcoder/index2.html

-----------------------------------------------

right now i implement a 68k system. 68ec000, 128kbyte flash, 256kbyte
ram..
this includes to write an assembler. it is more than 50 percent
complete.

now, the 68000 is microcode based (the chip contains a microcode
table).

can someone list up the difference between 68000/coldfire (in a few
lines)?

additionally, i plan to write assemblers for the SH2 (hitachi), and
probably even for the pentium. the implementation is in BASIC, and
highly relies on tables. additionally, a native version (which can
translate itself) is planned for the 68000 board.

the purpose is to write a few demos for the SEGA MEGA DRIVE.

recently i soldered in a PLCC version of the 68ec000, including bending
all the pins into flatpack style. for real flatpack, they are too small
for manual soldering.

>http://spaces.msn.com/members/afinn23console
--------------------------------------------------------------------

Aug 24, 2005, 8:23 AM

Post #5 of 17 (275 views)
Copy Shortcut
Re: [ColdFire] 68000/coldfire difference [In reply to] Can't Post

--------------------------------------------------------------------------------

>The Coldfire has almost the same programming model as the 68k. There are a
>few extra instructions (especially for cores with extra functionality, like
>a MAC unit), and it is missing some of the more obtuse addressing modes from
>later 68k chips. Otherwise, the real difference between the cores is that
>the Coldfire is far more efficient. There are, of course, huge differences
>between individual Coldfire chips and a 68000 chip - the ColdFire series are
>microcontrollers with lots of built-in peripherals, rather than just a plain
>cpu. You'd want to look at the Freescale web site to get summaries of the
>different Coldfire micros.

ColdFire limits its instruction/operand combinations to those that are
no longer than 48 bits. This means that many of the operand
combinations that were valid for the 68k are illegal for ColdFire.

Also most of the ColdFire instructions operate on 32 bit operands,
and have no 8 or 16 bit counterparts like the 68k has.

--
Peter Barada

--------------------------------------------------------------------

Message Edited by Dietrich on 04-03-2006 11:08 AM

Message Edited by Dietrich on 04-04-2006 01:38 PM

Re: 68000/coldfire difference

Dietrich — Sat, 01 Apr 2006 07:45:23 GMT

Aug 24, 2005, 3:20 PM

Post #6 of 17 (273 views)
Copy Shortcut
Re: [ColdFire] 68000/coldfire difference [In reply to] Can't Post

--------------------------------------------------------------------------------

I support a forth environment and have written an assembler for both the 68k
and the coldfire. If you want an instruction table go to cvs.cx and look
under either coldforth and Ucforth. and the file called assembler.4th

The coldfire instructions size is limited to 48bits, and that is absolute. The
DBRA instruction has gone probable never to come back and the MMOV with auto
increment and decrement have gone, never to come back. The others are
sneaking back in. The 4e core has everything you need, it gives back the
32bit branch ( which only existed in the later 68k cpu's) seriously needed if
you want to run position independent code ( libraries in a standard linux
environment). TAS is back, the separate stack for kernel space, bus errors
that stack a predictable stack. They are all back. And the 4e core runs about
10 times faster than anything ever offered in the 68k family.

In other words, the instruction table has to include a bit field indicating
which instruction is supported by which cpu. If you have an instruction table
for the 68k it is not a large job to get it into shape for the coldfire.

Just as instruction came and go in the 68k family they are coming in the
coldfire family ( I can't think of any coldfire going).

Take care to look at the MAC instructions, they have a lot of fields. This
differs from the 68k.

To my knowedge the coldfire programming manual is now 100% correct, you can
build you tables from scratch using just the documentation in the manual ( in
the early days there was problems).

It you have any questions just ask and I will attempt to answer them.

Regards
Charles Esson

On Wed, 24 Aug 2005 07:48 am, you wrote:
> right now i implement a 68k system. 68ec000, 128kbyte flash, 256kbyte ram.
> this includes to write an assembler. it is more than 50 percent complete.
>
> now, the 68000 is microcode based (the chip contains a microcode table).
>
> can someone list up the difference between 68000/coldfire (in a few lines)?
>
> additionally, i plan to write assemblers for the SH2 (hitachi), and
> probably even for the pentium. the implementation is in BASIC, and highly
> relies on tables. additionally, a native version (which can translate
> itself) is planned for the 68000 board.
>
> the purpose is to write a few demos for the SEGA MEGA DRIVE.
>
> recently i soldered in a PLCC version of the 68ec000, including bending all
> the pins into flatpack style. for real flatpack, they are too small for
> manual soldering.
>
> programming web space
> http://spaces.msn.com/members/afinn23console
>
>
> ---------------------------------
> How much free photo storage do you get? Store your holiday snaps for FREE
> with Yahoo! Photos. Get Yahoo! Photos

--
Charles Esson R&D group Colour Vision Systems
The views expressed herein are mine. No one else wants them.

Please sent attachments in PDF, HTML or TXT. Sorry but my spam filter now
rejects any message that contains <HTML> in the text. It was that or change
email address again.

--------------------------------------------------------------------

Aug 24, 2005, 4:41 PM

Post #7 of 17 (273 views)
Copy Shortcut
[ColdFire] please help with setup for the 5485 [In reply to] Can't Post

--------------------------------------------------------------------------------

I was hoping to get a little advice from this group on what
is required to finish my setup. I currently have the following
1) Eclipse development environment setup for the 5282 but no files for the
5485
2) The P&E parallel port BDM and the USB BDM
3) The P&E ICDCFZ debugger software
4) The Axiom 5485 board which comes with no actual support for the 5485!
(silly me for expecting it)
What I really need is a way to compile C code for the 5485 without spending
the next week fighting with an unsupported proccesor. Do I use the
Eclipse program and modify or get support for the 5485 or is there gcc
support for the 5485 or do I need to buy something like the P&E windows
integrated dev. editor. This is running on a Win2K machine, BTW.

Any advice is welcome.
Steve

--------------------------------------------------------------------

Aug 24, 2005, 4:52 PM

Post #8 of 17 (273 views)
Copy Shortcut
Re: [ColdFire] please help with setup for the 5485 [In reply to] Can't Post

--------------------------------------------------------------------------------

I am working with the 5485 using the evaluation board made by LogicPD. GCC is
available for the 5485. You should be able to get it running under Windows, I
believe Cybertec(www.cybertec.com.au) here in Australia sell a product called
crossfire which may be what you are after.

Alternatively, you could download the non-PCS linux development kit from
Metrowerks. It is free but it will only run under Linux which would mean you
would have to set up your machine to dual-boot. I have been using it, and it
compiles a bootloader and linux image that is not too hard to get running
from SDRAM via ethernet.

Thanks,

Corey

On Thu, 25 Aug 2005 09:41 am, Steve Letkeman wrote:
> I was hoping to get a little advice from this group on what
> is required to finish my setup. I currently have the following
> 1) Eclipse development environment setup for the 5282 but no files for the
> 5485
> 2) The P&E parallel port BDM and the USB BDM
> 3) The P&E ICDCFZ debugger software
> 4) The Axiom 5485 board which comes with no actual support for the 5485!
> (silly me for expecting it)
> What I really need is a way to compile C code for the 5485 without spending
> the next week fighting with an unsupported proccesor. Do I use the
> Eclipse program and modify or get support for the 5485 or is there gcc
> support for the 5485 or do I need to buy something like the P&E windows
> integrated dev. editor. This is running on a Win2K machine, BTW.
>
> Any advice is welcome.
> Steve

--------------------------------------------------------------------

Aug 30, 2005, 12:29 PM

Post #9 of 17 (267 views)
Copy Shortcut
[ColdFire] 5282 128 MBit x16 SDRAM A19 issue [In reply to] Can't Post

--------------------------------------------------------------------------------

Good day Everyone,

I was curious if anyone has had a similar problem to the one I am
experiencing with a 5282 connected to a single 128 MBit (16MByte) SDRAM
(Micron MT48LC8M16A2-75IT) in 16-bit mode. It is a custom 5282 design and
is similar to the various reference designs except there are source series
resistors with the Address lines. The SDRAM is connected to the 5282 as per
Table 15-14 in the 5272 User's manual and has also been verified to the
Avnet 5282 reference design.

Anyway, the problem is that I have unreliable reads and writes to specific
addresses where Address A19 is set. Addresses where A19 is clear, reading
and writing to the SDRAM is fine. I have tested several of our proto boards
and they all experience the same problem and at the same addresses.

To test the memory, I simply using the BDM with P&E's Coldfire Debugger and
BDM pod. If I manually change the problem addresses, the SDRAM correct
reads and writes the data. However, it is when I load a large file into
memory (where A19 is set) and then verify the contents do I see the problem.
I have also written a simple memory test routine and when loaded into the
"good" area of SDRAM and execute, I can see which addresses are the
culprits.

As for the hardware, I have double checked my signal integrity sims and they
look fine, although I could increase the series resistors somewhat (used 22
ohms, but could increase them to 82). Further, as a quick test of signal
integrity, I throttled down the 5282 from 64 Mhz to 32 Mhz and I get the
same repeatable results. I know that A19 is functioning correctly, as I am
able to read and write to my flash memory (which also uses A19) and there
are no problems (i.e. Address/Data bus is fine). I have scoped the various
signals (Address, BSx, CLKOUT, etc) with a FET input probe (<1pf Input
capacitance) and verified that all is in order.

Has anyone experienced an issue similar to this one, as I am somewhat
perplexed.

Thanks in advance!

Cheers,

Sam

Sam Saprunoff

--------------------------------------------------------------------

Aug 30, 2005, 1:31 PM

Post #10 of 17 (267 views)
Copy Shortcut
Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue [In reply to] Can't Post

--------------------------------------------------------------------------------

Sam

Do you have the Software Watchdog Timer turned off. On the 5282, it is
active cmming out of reset.

Dave

Sam Saprunoff wrote:

> Good day Everyone,
>
> I was curious if anyone has had a similar problem to the one I am
> experiencing with a 5282 connected to a single 128 MBit (16MByte)
> SDRAM (Micron MT48LC8M16A2-75IT) in 16-bit mode. It is a custom 5282
> design and is similar to the various reference designs except there
> are source series resistors with the Address lines. The SDRAM is
> connected to the 5282 as per Table 15-14 in the 5272 User's manual and
> has also been verified to the Avnet 5282 reference design.
>
> Anyway, the problem is that I have unreliable reads and writes to
> specific addresses where Address A19 is set. Addresses where A19 is
> clear, reading and writing to the SDRAM is fine. I have tested
> several of our proto boards and they all experience the same problem
> and at the same addresses.
>
> To test the memory, I simply using the BDM with P&E's Coldfire
> Debugger and BDM pod. If I manually change the problem addresses, the
> SDRAM correct reads and writes the data. However, it is when I load a
> large file into memory (where A19 is set) and then verify the contents
> do I see the problem. I have also written a simple memory test routine
> and when loaded into the "good" area of SDRAM and execute, I can see
> which addresses are the culprits.
>
> As for the hardware, I have double checked my signal integrity sims
> and they look fine, although I could increase the series resistors
> somewhat (used 22 ohms, but could increase them to 82). Further, as a
> quick test of signal integrity, I throttled down the 5282 from 64 Mhz
> to 32 Mhz and I get the same repeatable results. I know that A19 is
> functioning correctly, as I am able to read and write to my flash
> memory (which also uses A19) and there are no problems (i.e.
> Address/Data bus is fine). I have scoped the various signals
> (Address, BSx, CLKOUT, etc) with a FET input probe (<1pf Input
> capacitance) and verified that all is in order.
>
> Has anyone experienced an issue similar to this one, as I am somewhat
> perplexed.
>
> Thanks in advance!
>
> Cheers,
>
> Sam
>
> Sam Saprunoff

--------------------------------------------------------------------

Aug 30, 2005, 3:22 PM

Post #11 of 17 (267 views)
Copy Shortcut
Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue [In reply to] Can't Post

--------------------------------------------------------------------------------

Good day Dave,

Indeed. I even checked the register via the Debugger to ensure that the
Watchdog is disabled.

Cheers,

Sam

----- Original Message -----
From: "Dave Perreault"
Sent: Tuesday, August 30, 2005 2:31 PM
Subject: Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue

> Sam
>
> Do you have the Software Watchdog Timer turned off. On the 5282, it is
> active cmming out of reset.
>
> Dave
>
>

--------------------------------------------------------------------

Message Edited by Dietrich on 04-03-2006 11:07 AM

Message Edited by Dietrich on 04-04-2006 01:42 PM

Re: 68000/coldfire difference

Dietrich — Sat, 01 Apr 2006 07:45:58 GMT

Aug 30, 2005, 5:38 PM

Post #12 of 17 (267 views)
Copy Shortcut
RE: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue [In reply to] Can't Post

--------------------------------------------------------------------------------

A puzzler indeed...

Background: I've got a from scratch 5282 with a 32-bit 8 Mbyte (65M-bit)
Micron SDRAM on it. I have no resistors on the address or data lines. I
have 33 ohm resistors in series on all the control lines (close to the uP).
The main clock out has a 10 ohm resistor on it, and it goes to one other
part. The length of the control lines is about 4", the length of the
address and data lines is about 2". In the early "bring up the 1st board"
phase, the timing looked OK on a scope. The 33 ohms made the cleanest
control signals at the SDRAM, but that's tuned to this board so your mileage
may vary and you'll need to tweak the series control line resistors for your
board. BTW, I did test the 2nd board with both 22 and 51 ohm resistors to
be sure it wasn't all on the edge and working by accident.

Architecture comment: I have the SDRAM with a 32-bit connection, and the
FLASH with a 16-bit connection. I copy code from flash to sdram, yielding a
factor of 8-10 speed up. A FPGA also has a 16-bit interface. I know the
extra 16-bits are a routing pain, but it's really a big win on performance
especially with the small 2K cache- the cache fills twice as fast. Of
course all this depends on how much code is in the flash, how big the flash
is, how often it's execute, and other system considerations but the 32-bit
data path from sdram is a cheap factor of two speed up. When you add to
this the nature of the instruction set (variables really like to be 32-bits
so they match the native instruction set sizes), this makes even more sense.
I am kinda curious what sort of application would use 16 Mbytes of SDRAM and
not be too worried about speed (realize you might not be able to elaborate,
that's OK).

Comments: Not sure if the resistors are needed (realize there may be other
factors in play). My board's trace lengths and resistors are the poster
child for "don't need resistors in the address/data lines". A simple test
might be to short out some of the resistors (especially A19) and see if
anything changes.
Another "stupid board trick" to try is put a weak (5K-ish) pull-up
resistor on A19, and see if things are different or if now only hi address
lines work. Note also that a "pull up on A19" could really mean a pull up
on the address line in for the mux into the SDRAM that will have A19 on it
(as per the various connection tables in the manual). You said that "I know
A19 is good because my flash is happy (my paraphrase...)", but be sure the
check the address line that has A19 on when the SDRAM controller is muxing
the address into the SDRAM.
If you still have the problem when you cut the CPU speed in half, is sure
sounds like it's not a timing issue (setup and hold), but it could still be
a race condition on various edges or a floating pin.
You might also check the pin set-ups for the address lines and control
signals. Often with the 5282 you have to deal with a few different sections
of the manual to get things set up, and it's not always obvious which
sections you'll need to deal with.
So carefully check the PFPAR and port G and H.

I'd like give you a "here you go" answer, hope these thoughts will trigger
some ideas on new places to look for solutions.

- pete

> -----Original Message-----
> From: On
> Behalf Of Sam Saprunoff
> Sent: Tuesday, August 30, 2005 3:30 PM
> Subject: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue
>
> Good day Everyone,
>
> I was curious if anyone has had a similar problem to the one I am
> experiencing with a 5282 connected to a single 128 MBit (16MByte) SDRAM
> (Micron MT48LC8M16A2-75IT) in 16-bit mode. It is a custom 5282 design and
> is similar to the various reference designs except there are source series
> resistors with the Address lines. The SDRAM is connected to the 5282 as
> per
> Table 15-14 in the 5272 User's manual and has also been verified to the
> Avnet 5282 reference design.
>
> Anyway, the problem is that I have unreliable reads and writes to specific
> addresses where Address A19 is set. Addresses where A19 is clear, reading
> and writing to the SDRAM is fine. I have tested several of our proto
> boards
> and they all experience the same problem and at the same addresses.
>
> To test the memory, I simply using the BDM with P&E's Coldfire Debugger
> and
> BDM pod. If I manually change the problem addresses, the SDRAM correct
> reads and writes the data. However, it is when I load a large file into
> memory (where A19 is set) and then verify the contents do I see the
> problem.
> I have also written a simple memory test routine and when loaded into the
> "good" area of SDRAM and execute, I can see which addresses are the
> culprits.
>
> As for the hardware, I have double checked my signal integrity sims and
> they
> look fine, although I could increase the series resistors somewhat (used
> 22
> ohms, but could increase them to 82). Further, as a quick test of signal
> integrity, I throttled down the 5282 from 64 Mhz to 32 Mhz and I get the
> same repeatable results. I know that A19 is functioning correctly, as I
> am
> able to read and write to my flash memory (which also uses A19) and there
> are no problems (i.e. Address/Data bus is fine). I have scoped the
> various
> signals (Address, BSx, CLKOUT, etc) with a FET input probe (<1pf Input
> capacitance) and verified that all is in order.
>
> Has anyone experienced an issue similar to this one, as I am somewhat
> perplexed.
>
> Thanks in advance!
>
> Cheers,
>
> Sam
>
> Sam Saprunoff

--------------------------------------------------------------------

Aug 31, 2005, 8:33 AM

Post #13 of 17 (267 views)
Copy Shortcut
Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue [In reply to] Can't Post

--------------------------------------------------------------------------------

Good day Peter,

Thank you for the background info and debugging suggestions. My next step
was to start "playing" with A19, etc but I thought an e-mail "distress" call
might reflect another issue that I was unware of ...

Your background info is very helpful and has similar trace characteristics
to mine. My address and data lines are approx 1.6" long and the control
lines around 2.2". I am starting with the reference designs 22 ohms, but
can see that I can increase these to improve the signals. As you have done,
I will be tuning these to the layout.

In regards to the architecture, we went with the x16 16MB SDRAM for several
reasons.

1. The cost differential for the 16MB was not very much different than
the 8MB (at least in the Industrial temp range).
2. Larger number of 2nd source suppliers of Industrial 16MB parts
3. Most of our disti's had greater current stock of the 16 MB and had
more future orders for the 16 MB
(read this as potentially easier to obtain)

A x16 bit configuration was chosen to minimize the overall board size and
the number of PCB layers (6). Given the design's functionality and
physicality (height, width, length... all dimensions... yikes) requirements,
we had to squeeze in a lot in a small space:

3.4" x 3.6" PCB
on-board 3.3V / 5V Power supplies
5282 with 16MB SDRAM, 2-8 MB of Flash
10/100 PHY (AMD79C874)
RTC with on-board 3V cell and holder
Dual Footprint Atmel Serial DataFlash
Xilinx CPLD (95144XL)
Break out of 5282's A/D inputs,etc
BDM Interface
Break-out a vast number of I/O to SMT connectors
All components Industrial Temp Rated

Surprisingly, overall performance was not a major design requirement. The
5282 in itself is totally overkill for our applications, but was chosen
because of the rich peripherals, adbundant software tools (Metrowerks, etc),
etc. We wanted to have a core design that would suit all of our current and
future product needs that could not be met with other devices such as the
HC12, etc. Basically this design is like a "Rabbitcore" module for Rabbit
Semiconductor, but with much greater functionality and flexibility.

Anyway, I digress...

Thanks again for your suggestions and info! I will report back once I
discovered the issue(s).

Cheers,

Sam

----- Original Message -----
From: "Peter Hallenbeck"

Sent: Tuesday, August 30, 2005 6:38 PM
Subject: RE: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue

A puzzler indeed...

I'd like give you a "here you go" answer, hope these thoughts will trigger
some ideas on new places to look for solutions.

- pete

--------------------------------------------------------------------

Message Edited by Dietrich on 04-03-2006 11:06 AM

Message Edited by Dietrich on 04-04-2006 01:43 PM

Re: 68000/coldfire difference

Dietrich — Sat, 01 Apr 2006 07:46:17 GMT

Aug 31, 2005, 9:03 AM

Post #14 of 17 (267 views)
Copy Shortcut
Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue [In reply to] Can't Post

--------------------------------------------------------------------------------

Hello Sam,

Could you show us the contents of the SDRAM control registers please (DCR,
DACR0, DMR0, DACR1, DMR1)?

Regards,
Stephen.

----- Original Message -----
From: "Sam Saprunoff"
Sent: Wednesday, August 31, 2005 5:29 AM
Subject: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue

> Good day Everyone,
>
> I was curious if anyone has had a similar problem to the one I am
> experiencing with a 5282 connected to a single 128 MBit (16MByte) SDRAM
> (Micron MT48LC8M16A2-75IT) in 16-bit mode. It is a custom 5282 design and
> is similar to the various reference designs except there are source series
> resistors with the Address lines. The SDRAM is connected to the 5282 as
> per Table 15-14 in the 5272 User's manual and has also been verified to
> the Avnet 5282 reference design.
>
> Anyway, the problem is that I have unreliable reads and writes to specific
> addresses where Address A19 is set. Addresses where A19 is clear, reading
> and writing to the SDRAM is fine. I have tested several of our proto
> boards and they all experience the same problem and at the same addresses.

--------------------------------------------------------------------

Aug 31, 2005, 10:13 AM

Post #15 of 17 (267 views)
Copy Shortcut
Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue [In reply to] Can't Post

--------------------------------------------------------------------------------

Good day Stephen,

I only have a single SDRAM connected to nSCS0 and so DACR1/DMR1 are not
used.

The registers have been set to:

DCR 0x023E
5282 does the Row/Col muxing
Refresh timing = 6 clocks
Refresh Count = 0x3E (clock is 64Mhz)
(Adjusting slightly higher or lower has no effect to the problem at
hand)

DACR0 0x10001420
Base Addr = 0x1000
CASL = 01
CBM = 100
Port Size= 10 (16 bit)

DMR0 0x00fc0001
BAM = 0x00fc (16 MByte)
WP =0
AMx = 0
Valid = 1

DACR1 (not Used) but cleared
DMR1 (not Used) but cleared

Cheers,

Sam

----- Original Message -----
From: "Stephen Smith"
Sent: Wednesday, August 31, 2005 10:03 AM
Subject: Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue

> Hello Sam,
>
> Could you show us the contents of the SDRAM control registers please (DCR,
> DACR0, DMR0, DACR1, DMR1)?
>
>
> Regards,
> Stephen.
>
>
> ----- Original Message -----
> From: "Sam Saprunoff"
> Sent: Wednesday, August 31, 2005 5:29 AM
> Subject: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue
>
>
>> Good day Everyone,
>>
>> I was curious if anyone has had a similar problem to the one I am
>> experiencing with a 5282 connected to a single 128 MBit (16MByte) SDRAM
>> (Micron MT48LC8M16A2-75IT) in 16-bit mode. It is a custom 5282 design
>> and is similar to the various reference designs except there are source
>> series resistors with the Address lines. The SDRAM is connected to the
>> 5282 as per Table 15-14 in the 5272 User's manual and has also been
>> verified to the Avnet 5282 reference design.
>>
>> Anyway, the problem is that I have unreliable reads and writes to
>> specific addresses where Address A19 is set. Addresses where A19 is
>> clear, reading and writing to the SDRAM is fine. I have tested several
>> of our proto boards and they all experience the same problem and at the
>> same addresses.

--------------------------------------------------------------------

Aug 31, 2005, 1:32 PM

Post #16 of 17 (267 views)
Copy Shortcut
Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue [In reply to] Can't Post

--------------------------------------------------------------------------------

Hello Sam,

Thanks. Try setting CBM in DACR0 to 011, since the SDRAM command bit (A10)
is A20 and not A21.

Regards,
Stephen.

----- Original Message -----
From: "Sam Saprunoff"
Sent: Thursday, September 01, 2005 3:13 AM
Subject: Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue

> Good day Stephen,
>
> I only have a single SDRAM connected to nSCS0 and so DACR1/DMR1 are not
> used.
>
> The registers have been set to:
>
> DCR 0x023E
> 5282 does the Row/Col muxing
> Refresh timing = 6 clocks
> Refresh Count = 0x3E (clock is 64Mhz)
> (Adjusting slightly higher or lower has no effect to the problem at
> hand)
>
> DACR0 0x10001420
> Base Addr = 0x1000
> CASL = 01
> CBM = 100
> Port Size= 10 (16 bit)
>
> DMR0 0x00fc0001
> BAM = 0x00fc (16 MByte)
> WP =0
> AMx = 0
> Valid = 1
>
> DACR1 (not Used) but cleared
> DMR1 (not Used) but cleared
>
> Cheers,
>
> Sam
>
>
> ----- Original Message -----
> From: "Stephen Smith">

> Sent: Wednesday, August 31, 2005 10:03 AM
> Subject: Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue
>
>
>> Hello Sam,
>>
>> Could you show us the contents of the SDRAM control registers please
>> (DCR, DACR0, DMR0, DACR1, DMR1)?
>>
>>
>> Regards,
>> Stephen.
>>
>>
>> ----- Original Message -----
>> From: "Sam Saprunoff"
>> Sent: Wednesday, August 31, 2005 5:29 AM
>> Subject: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue
>>
>>
>>> Good day Everyone,
>>>
>>> I was curious if anyone has had a similar problem to the one I am
>>> experiencing with a 5282 connected to a single 128 MBit (16MByte) SDRAM
>>> (Micron MT48LC8M16A2-75IT) in 16-bit mode. It is a custom 5282 design
>>> and is similar to the various reference designs except there are source
>>> series resistors with the Address lines. The SDRAM is connected to the
>>> 5282 as per Table 15-14 in the 5272 User's manual and has also been
>>> verified to the Avnet 5282 reference design.
>>>
>>> Anyway, the problem is that I have unreliable reads and writes to
>>> specific addresses where Address A19 is set. Addresses where A19 is
>>> clear, reading and writing to the SDRAM is fine. I have tested several
>>> of our proto boards and they all experience the same problem and at the
>>> same addresses.
>>
>>
>> --------------------------------------------------------------------

--------------------------------------------------------------------
Aug 31, 2005, 3:10 PM

Post #17 of 17 (267 views)
Copy Shortcut
Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue [In reply to] Can't Post

--------------------------------------------------------------------------------

Good day Stephen,

Thanks for the suggestion... That's what did it! All is working correctly!
I reviewed the CBM table and given that my bank select bits are 22 and 23, I
naturally thought CBM should be 100...silly me...

Thanks again Stephen and to all who assisted!

Cheers,

Sam

----- Original Message -----
From: "Stephen Smith"
Sent: Wednesday, August 31, 2005 2:32 PM
Subject: Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue

> Hello Sam,
>
> Thanks. Try setting CBM in DACR0 to 011, since the SDRAM command bit
> (A10) is A20 and not A21.
>
>
> Regards,
> Stephen.
>
>
> ----- Original Message -----
> From: "Sam Saprunoff"
> Sent: Thursday, September 01, 2005 3:13 AM
> Subject: Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue
>
>
>> Good day Stephen,
>>
>> I only have a single SDRAM connected to nSCS0 and so DACR1/DMR1 are not
>> used.
>>
>> The registers have been set to:
>>
>> DCR 0x023E
>> 5282 does the Row/Col muxing
>> Refresh timing = 6 clocks
>> Refresh Count = 0x3E (clock is 64Mhz)
>> (Adjusting slightly higher or lower has no effect to the problem
>> at hand)
>>
>> DACR0 0x10001420
>> Base Addr = 0x1000
>> CASL = 01
>> CBM = 100
>> Port Size= 10 (16 bit)
>>
>> DMR0 0x00fc0001
>> BAM = 0x00fc (16 MByte)
>> WP =0
>> AMx = 0
>> Valid = 1
>>
>> DACR1 (not Used) but cleared
>> DMR1 (not Used) but cleared
>>
>> Cheers,
>>
>> Sam
>>
>>
>> ----- Original Message -----
>> From: "Stephen Smith"
>> Sent: Wednesday, August 31, 2005 10:03 AM
>> Subject: Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue
>>
>>
>>> Hello Sam,
>>>
>>> Could you show us the contents of the SDRAM control registers please
>>> (DCR, DACR0, DMR0, DACR1, DMR1)?
>>>
>>>
>>> Regards,
>>> Stephen.
>>>
>>>
>>> ----- Original Message -----
>>> From: "Sam Saprunoff"
>>> Sent: Wednesday, August 31, 2005 5:29 AM
>>> Subject: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue
>>>
>>>
>>>> Good day Everyone,
>>>>
>>>> I was curious if anyone has had a similar problem to the one I am
>>>> experiencing with a 5282 connected to a single 128 MBit (16MByte) SDRAM
>>>> (Micron MT48LC8M16A2-75IT) in 16-bit mode. It is a custom 5282 design
>>>> and is similar to the various reference designs except there are source
>>>> series resistors with the Address lines. The SDRAM is connected to the
>>>> 5282 as per Table 15-14 in the 5272 User's manual and has also been
>>>> verified to the Avnet 5282 reference design.
>>>>
>>>> Anyway, the problem is that I have unreliable reads and writes to
>>>> specific addresses where Address A19 is set. Addresses where A19 is
>>>> clear, reading and writing to the SDRAM is fine. I have tested several
>>>> of our proto boards and they all experience the same problem and at the
>>>> same addresses.

Message Edited by Dietrich on 04-03-2006 11:03 AM

Message Edited by Dietrich on 04-04-2006 01:45 PM