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 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
Copy Shortcut
RE: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue [In reply to] Can't Post
--------------------------------------------------------------------------------
A puzzler indeed...
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.
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).
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.
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.
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
> 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
Copy Shortcut
Re: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue [In reply to] Can't Post
--------------------------------------------------------------------------------
Good day Peter,
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
...
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.
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.
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)
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:
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
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.
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).
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
Subject: RE: [ColdFire] 5282 128 MBit x16 SDRAM A19 issue
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.
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).
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.
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.
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
> 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
--------------------------------------------------------------------
Message Edited by Dietrich on 04-03-2006 11:06 AM
Message Edited by Dietrich on 04-04-2006 01:43 PM
