C6722 EMIF error signal

HI

My system is a C6722 DSP with a Micron MT48LC4M16A2-75 SDRAM. Everything works fine now but some problem with the SDRAM, there are sometimes a undesired bit (or sometimes more than one) appeared when I read the data from SDRAM in the CCS.

I inputed a sine wave (1KHz) into the ADC, the dMAX then copy it into the internal memory. My C code then copys the data from the internal memory into the external memory, namely SDRAM.

Using the CCS Graph function, I should see exactly the same sine wave from both internal and external memory, and I do see the same graph for most of the time. But sometimes there are extra bits appear only on the SDRAM side. So it must be somethings wrong between the DSP and SDRAM.

By the extra bit, I mean a correct data word 00000000000000000000000000111111 appeared as 0000000"1"000000000000000000111111. One or more (2~3) extra bits appeard. It appeared randomly but some data bits more often appear error bit than others. The errors appeared address are random as well.

There are two methods that I can make the error bit temporarily disappear.
First method is keep refreshing the graph window, then error will disappear and the correct sine waves are shown. But sometimes it will get worst.

Second method is used when the error bit won't disappear when I refreshing the graph window. I can hook an oscilloscope probe to the data pin that appear the error bit, then the error bit will disappear. But when I remove the probe, the error bit back again.

This issue makes my SDRAM unreliable. I suspect that it is caused by the EMI, but I am not really sure about that. Anyone have any idea what might be going wrong? All suggestions are welcome. Any help would be appreciated.

PS. DSP @ 200MHz and EMIF @ 100MHz.
PS.. It happened when the EMIF @ 80MHz

Best regards

Peter Start a New Thread

Hello Peter,

On Sun, Jul 6, 2008 at 9:22 PM, wrote:
> HI
>
> My system is a C6722 DSP with a Micron MT48LC4M16A2-75 SDRAM. Everything
> works fine now but some problem with the SDRAM, there are sometimes a
> undesired bit (or sometimes more than one) appeared when I read the data
> from SDRAM in the CCS.
>
> I inputed a sine wave (1KHz) into the ADC, the dMAX then copy it into the
> internal memory. My C code then copys the data from the internal memory into
> the external memory, namely SDRAM.
>
> Using the CCS Graph function, I should see exactly the same sine wave from
> both internal and external memory, and I do see the same graph for most of
> the time. But sometimes there are extra bits appear only on the SDRAM side.
> So it must be somethings wrong between the DSP and SDRAM.
>
> By the extra bit, I mean a correct data word
> 00000000000000000000000000111111 appeared as
> 0000000"1"000000000000000000111111. One or more (2~3) extra bits appeard. It
> appeared randomly but some data bits more often appear error bit than
> others. The errors appeared address are random as well.
>
> There are two methods that I can make the error bit temporarily disappear.
> First method is keep refreshing the graph window, then error will disappear
> and the correct sine waves are shown. But sometimes it will get worst.

I don't put much stock in "what this means" - it usually means
that something could be wrong somewhere. Keep in mind that every time
that you hit refresh on 6727 the DSP is halted. This halt appears
'some where in the execution of your code'. DMA continuing with the
DSP halted, interrupts missed with the DSP halted, etc. can cause some
weird side effects.
>
> Second method is used when the error bit won't disappear when I refreshing
> the graph window. I can hook an oscilloscope probe to the data pin that
> appear the error bit, then the error bit will disappear. But when I remove
> the probe, the error bit back again.


This seems to point to a timing problem.

I suggest trying to piece together a deterministic example test to try
to 'catch the failure'.

If you don't find an obvious problem, the memory subsystem should be reviewed.
---paste from another message on the question ""But it's sure that the
data after LDW is wrong, because the one in memory is still right. I
just want to know if such kinds of problem is general or can only be
seen very seldom? ---
<>
The answer for me is NEVER when the following are correct [I may have
left out a few]:
NOTE: TI DSPs are used in several critical applications that require
100% repeatability.
1. The experiment is performed by running the DSP [not single
stepping, modifying registers, etc].
2. Program software can cause intermittent 'strange problems' [bad
assembly code that works 99.9% of the time, 'C' pointer problems,
arrays/buffers going beyond their allocation, incorrect algorithms
that work 99% of the time, etc]
3. Voltages [checked with a scope, not a meter]. Sometimes switching
power supplies are not filtered as well as you think.
4. Board design - power and ground planes, analog/digital ground
separation, other good board design practices [i.e. a bad practice
would be to put a switching power supply right next to the DSP or
PLL].
5. Board environment - setting the board on top of a CRT monitor while
running it can cause mystery problems.
6. Electrical environment - plugging the AC into an outlet that is
shared with a large AC motor [which could be on the other side of the
wall].
7. Board assembly - all pins/balls must be soldered [as previously
mentioned]. If you take the extreme case of only 1 or 2 core voltage
or ground pins soldered - everything might 'look ok most of the time'
for simple stuff, but you will get 'strange behavior' that may or may
not be repeatable.

I have 'gotten gray hair' from scenarios similar to the above examples.
--- end paste ---
>
> This issue makes my SDRAM unreliable. I suspect that it is caused by the
> EMI, but I am not really sure about that. Anyone have any idea what might be
> going wrong? All suggestions are welcome. Any help would be appreciated.
>
> PS. DSP @ 200MHz and EMIF @ 100MHz.
> PS.. It happened when the EMIF @ 80MHz

One question might be your EMIF settings. Are they correct??
Trying intentionally adding +1 to your EMIF clock settings just to see
what happens.

mikedunn
> Best regards
>
> Peter

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php Start a New Thread

Peter-

> My system is a C6722 DSP with a Micron MT48LC4M16A2-75 SDRAM.
> Everything works fine now but some problem with the SDRAM, there
> are sometimes a undesired bit (or sometimes more than one)
> appeared when I read the data from SDRAM in the CCS.
>
> I inputed a sine wave (1KHz) into the ADC, the dMAX then copy it
> into the internal memory. My C code then copys the data from the
> internal memory into the external memory, namely SDRAM.
>
> Using the CCS Graph function, I should see exactly the same sine
> wave from both internal and external memory, and I do see the
> same graph for most of the time. But sometimes there are extra
> bits appear only on the SDRAM side. So it must be somethings
> wrong between the DSP and SDRAM.
>
> By the extra bit, I mean a correct data word
> 00000000000000000000000000111111 appeared as
> 0000000"1"000000000000000000111111. One or more (2~3) extra bits
> appeard. It appeared randomly but some data bits more often
> appear error bit than others. The errors appeared address are
> random as well.
>
> There are two methods that I can make the error bit temporarily
> disappear. First method is keep refreshing the graph window,
> then error will disappear and the correct sine waves are shown.
> But sometimes it will get worst.
>
> Second method is used when the error bit won't disappear when
> I refreshing the graph window. I can hook an oscilloscope probe
> to the data pin that appear the error bit, then the error bit
> will disappear. But when I remove the probe, the error bit back
> again.
>
> This issue makes my SDRAM unreliable. I suspect that it is
> caused by the EMI, but I am not really sure about that. Anyone
> have any idea what might be going wrong? All suggestions are
> welcome. Any help would be appreciated.
>
> PS. DSP @ 200MHz and EMIF @ 100MHz.
> PS.. It happened when the EMIF @ 80MHz

First, I agree with Mike, it's probably a timing issue. Your comment about a scope
probe affecting the results seems to support that theory, although it could also mean
your board layout has some issues. To help isolate, make sure your scope probe is an
'active' probe with very high input impedance, and that you keep your scope leads
extremely short (including gnd lead). What you're looking for is shape of the signal
-- overshoot and undershoot need to be within specs in the DSP and SDRAM data sheets.

Second, are you changing your EMIF register settings (either or both .gel file and in
your program code) depending on your EMIF clock rate? If the clock rate changes,
then some SDRAM settings such as CAS latency may change.

-Jeff Start a New Thread

Peter-

> Mike and Jeff. Thanks for your reply.
>
> First, about the timing issue. I really don't understand that how the
> scope probe affects the timing. I thought there are some kind of EMI
> noise around the memory circuit, and the scope probe helps reduce the
> noise. Apparently I am overruled. Could you please explain a little
> bit for me.

The scope probe can load the signal -- bit of extra capacitance, possibly bit of
extra R depending on the probe impedance. Of course can "shape" the signal --
obviously not desirable for purposes of accurate measurement. (As a fun academic
exercise, look up "observer effect" and "Heisenberg Uncertainty Principle").

The effect of such shaping may reduce unwanted noise a little (good). It may also
slew the signal (change rise/fall time) differently than predicted by high-speed
signal simulation of your board layout (bad). Just guessing, but in your case, it
might be that it slows down the data bit in question, which somehow fixes a marginal
timing problem. If that were really happening, then here are some questions for you:

-are all of your data traces (in the layout)
equal length between the DSP and SDRAM?

-do all data traces have zero-ohm Rs or none
of them?

-are some data traces connected also to
Flash (or FPGA or other peripheral) and
some are not?

-Jeff

> Second, about the EMIF setup. There is an example of the EMIF setup in
> the C672X EMIF manual that configures the MT48LC4M16A2-75 memory
> (which is the same one that I am using). I setup the EMIF according to
> it. Of course I also did the calculation based on the memory datasheet
> to verify it. So hopefully there should not be any error here. But I
> won't rule out the possibility that it might cause my EMIF problem.
>
> I also reconfigured the EMIF when I tried to eliminate the problem by
> solwing down the EMIF clock rate.
>
> I am varying the EMIF value like Mike said to see what will be going on.
>
> Best regards
> Peter
>
> On 08/07/2008, Michael Dunn wrote:
> > Hello Peter,
> >
> > On Sun, Jul 6, 2008 at 9:22 PM, wrote:
> >> HI
> >>
> >> My system is a C6722 DSP with a Micron MT48LC4M16A2-75 SDRAM. Everything
> >> works fine now but some problem with the SDRAM, there are sometimes a
> >> undesired bit (or sometimes more than one) appeared when I read the data
> >> from SDRAM in the CCS.
> >>
> >> I inputed a sine wave (1KHz) into the ADC, the dMAX then copy it into the
> >> internal memory. My C code then copys the data from the internal memory
> >> into
> >> the external memory, namely SDRAM.
> >>
> >> Using the CCS Graph function, I should see exactly the same sine wave from
> >> both internal and external memory, and I do see the same graph for most of
> >> the time. But sometimes there are extra bits appear only on the SDRAM
> >> side.
> >> So it must be somethings wrong between the DSP and SDRAM.
> >>
> >> By the extra bit, I mean a correct data word
> >> 00000000000000000000000000111111 appeared as
> >> 0000000"1"000000000000000000111111. One or more (2~3) extra bits appeard.
> >> It
> >> appeared randomly but some data bits more often appear error bit than
> >> others. The errors appeared address are random as well.
> >>
> >> There are two methods that I can make the error bit temporarily disappear.
> >> First method is keep refreshing the graph window, then error will
> >> disappear
> >> and the correct sine waves are shown. But sometimes it will get worst.
> >
> > I don't put much stock in "what this means" - it usually means
> > that something could be wrong somewhere. Keep in mind that every time
> > that you hit refresh on 6727 the DSP is halted. This halt appears
> > 'some where in the execution of your code'. DMA continuing with the
> > DSP halted, interrupts missed with the DSP halted, etc. can cause some
> > weird side effects.
> >>
> >> Second method is used when the error bit won't disappear when I refreshing
> >> the graph window. I can hook an oscilloscope probe to the data pin that
> >> appear the error bit, then the error bit will disappear. But when I remove
> >> the probe, the error bit back again.
> >
> >
> > This seems to point to a timing problem.
> >
> > I suggest trying to piece together a deterministic example test to try
> > to 'catch the failure'.
> >
> > If you don't find an obvious problem, the memory subsystem should be
> > reviewed.
> > ---paste from another message on the question ""But it's sure that the
> > data after LDW is wrong, because the one in memory is still right. I
> > just want to know if such kinds of problem is general or can only be
> > seen very seldom? ---
> > <>
> > The answer for me is NEVER when the following are correct [I may have
> > left out a few]:
> > NOTE: TI DSPs are used in several critical applications that require
> > 100% repeatability.
> > 1. The experiment is performed by running the DSP [not single
> > stepping, modifying registers, etc].
> > 2. Program software can cause intermittent 'strange problems' [bad
> > assembly code that works 99.9% of the time, 'C' pointer problems,
> > arrays/buffers going beyond their allocation, incorrect algorithms
> > that work 99% of the time, etc]
> > 3. Voltages [checked with a scope, not a meter]. Sometimes switching
> > power supplies are not filtered as well as you think.
> > 4. Board design - power and ground planes, analog/digital ground
> > separation, other good board design practices [i.e. a bad practice
> > would be to put a switching power supply right next to the DSP or
> > PLL].
> > 5. Board environment - setting the board on top of a CRT monitor while
> > running it can cause mystery problems.
> > 6. Electrical environment - plugging the AC into an outlet that is
> > shared with a large AC motor [which could be on the other side of the
> > wall].
> > 7. Board assembly - all pins/balls must be soldered [as previously
> > mentioned]. If you take the extreme case of only 1 or 2 core voltage
> > or ground pins soldered - everything might 'look ok most of the time'
> > for simple stuff, but you will get 'strange behavior' that may or may
> > not be repeatable.
> >
> > I have 'gotten gray hair' from scenarios similar to the above examples.
> > --- end paste ---
> >
> >
> >>
> >> This issue makes my SDRAM unreliable. I suspect that it is caused by the
> >> EMI, but I am not really sure about that. Anyone have any idea what might
> >> be
> >> going wrong? All suggestions are welcome. Any help would be appreciated.
> >>
> >> PS. DSP @ 200MHz and EMIF @ 100MHz.
> >> PS.. It happened when the EMIF @ 80MHz
> >
> > One question might be your EMIF settings. Are they correct??
> > Trying intentionally adding +1 to your EMIF clock settings just to see
> > what happens.
> >
> > mikedunn
> >> Best regards
> >>
> >> Peter Start a New Thread

Hi

Mike and Jeff. Thanks for your reply.

First, about the timing issue. I really don't understand that how the
scope probe affects the timing. I thought there are some kind of EMI
noise around the memory circuit, and the scope probe helps reduce the
noise. Apparently I am overruled. Could you please explain a little
bit for me.

Second, about the EMIF setup. There is an example of the EMIF setup in
the C672X EMIF manual that configures the MT48LC4M16A2-75 memory
(which is the same one that I am using). I setup the EMIF according to
it. Of course I also did the calculation based on the memory datasheet
to verify it. So hopefully there should not be any error here. But I
won't rule out the possibility that it might cause my EMIF problem.

I also reconfigured the EMIF when I tried to eliminate the problem by
solwing down the EMIF clock rate.

I am varying the EMIF value like Mike said to see what will be going on.

Best regards
Peter

On 08/07/2008, Michael Dunn wrote:
> Hello Peter,
>
> On Sun, Jul 6, 2008 at 9:22 PM, wrote:
>> HI
>>
>> My system is a C6722 DSP with a Micron MT48LC4M16A2-75 SDRAM. Everything
>> works fine now but some problem with the SDRAM, there are sometimes a
>> undesired bit (or sometimes more than one) appeared when I read the data
>> from SDRAM in the CCS.
>>
>> I inputed a sine wave (1KHz) into the ADC, the dMAX then copy it into the
>> internal memory. My C code then copys the data from the internal memory
>> into
>> the external memory, namely SDRAM.
>>
>> Using the CCS Graph function, I should see exactly the same sine wave from
>> both internal and external memory, and I do see the same graph for most of
>> the time. But sometimes there are extra bits appear only on the SDRAM
>> side.
>> So it must be somethings wrong between the DSP and SDRAM.
>>
>> By the extra bit, I mean a correct data word
>> 00000000000000000000000000111111 appeared as
>> 0000000"1"000000000000000000111111. One or more (2~3) extra bits appeard.
>> It
>> appeared randomly but some data bits more often appear error bit than
>> others. The errors appeared address are random as well.
>>
>> There are two methods that I can make the error bit temporarily disappear.
>> First method is keep refreshing the graph window, then error will
>> disappear
>> and the correct sine waves are shown. But sometimes it will get worst.
>
> I don't put much stock in "what this means" - it usually means
> that something could be wrong somewhere. Keep in mind that every time
> that you hit refresh on 6727 the DSP is halted. This halt appears
> 'some where in the execution of your code'. DMA continuing with the
> DSP halted, interrupts missed with the DSP halted, etc. can cause some
> weird side effects.
>>
>> Second method is used when the error bit won't disappear when I refreshing
>> the graph window. I can hook an oscilloscope probe to the data pin that
>> appear the error bit, then the error bit will disappear. But when I remove
>> the probe, the error bit back again.
>
>
> This seems to point to a timing problem.
>
> I suggest trying to piece together a deterministic example test to try
> to 'catch the failure'.
>
> If you don't find an obvious problem, the memory subsystem should be
> reviewed.
> ---paste from another message on the question ""But it's sure that the
> data after LDW is wrong, because the one in memory is still right. I
> just want to know if such kinds of problem is general or can only be
> seen very seldom? ---
> <>
> The answer for me is NEVER when the following are correct [I may have
> left out a few]:
> NOTE: TI DSPs are used in several critical applications that require
> 100% repeatability.
> 1. The experiment is performed by running the DSP [not single
> stepping, modifying registers, etc].
> 2. Program software can cause intermittent 'strange problems' [bad
> assembly code that works 99.9% of the time, 'C' pointer problems,
> arrays/buffers going beyond their allocation, incorrect algorithms
> that work 99% of the time, etc]
> 3. Voltages [checked with a scope, not a meter]. Sometimes switching
> power supplies are not filtered as well as you think.
> 4. Board design - power and ground planes, analog/digital ground
> separation, other good board design practices [i.e. a bad practice
> would be to put a switching power supply right next to the DSP or
> PLL].
> 5. Board environment - setting the board on top of a CRT monitor while
> running it can cause mystery problems.
> 6. Electrical environment - plugging the AC into an outlet that is
> shared with a large AC motor [which could be on the other side of the
> wall].
> 7. Board assembly - all pins/balls must be soldered [as previously
> mentioned]. If you take the extreme case of only 1 or 2 core voltage
> or ground pins soldered - everything might 'look ok most of the time'
> for simple stuff, but you will get 'strange behavior' that may or may
> not be repeatable.
>
> I have 'gotten gray hair' from scenarios similar to the above examples.
> --- end paste ---
>>
>> This issue makes my SDRAM unreliable. I suspect that it is caused by the
>> EMI, but I am not really sure about that. Anyone have any idea what might
>> be
>> going wrong? All suggestions are welcome. Any help would be appreciated.
>>
>> PS. DSP @ 200MHz and EMIF @ 100MHz.
>> PS.. It happened when the EMIF @ 80MHz
>
> One question might be your EMIF settings. Are they correct??
> Trying intentionally adding +1 to your EMIF clock settings just to see
> what happens.
>
> mikedunn
>> Best regards
>>
>> Peter
>>
>> --
> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
> Start a New Thread

HI

Thanks for your explanation, Jeff.
To answer Jeff's question first.

> -are all of your data traces (in the layout)
> equal length between the DSP and SDRAM?

They are not equal length, the difference is less than 3cm.

-do all data traces have zero-ohm Rs or none
of them?

Do you mean a zero-ohm resister on the traces or the resistance of the
line is zero ohm?
There is no zero-ohm resister connect to the traces, and the line
resistance is almost 0 ohm (according to a normal multi-meter).

-are some data traces connected also to
Flash (or FPGA or other peripheral) and
some are not?

I used to connect them to a Flash memory, but I have removed it.
There is a strange symptom happened, when I trying to move the data
into the SDRAM.

My data are 32-bit word, but I only use the lower 17 bits, the rest of
bits are paded with zeros. When I left shift the data for 4 bits,
which the data reach the bit 20, the problem disappeared. I have
measured the track, but there is no connection problem, (as far as I
can see). What does this mean? A board problem?

Best regards
Peter

On 08/07/2008, Jeff Brower wrote:
> Peter-
>
>> Mike and Jeff. Thanks for your reply.
>>
>> First, about the timing issue. I really don't understand that how the
>> scope probe affects the timing. I thought there are some kind of EMI
>> noise around the memory circuit, and the scope probe helps reduce the
>> noise. Apparently I am overruled. Could you please explain a little
>> bit for me.
>
> The scope probe can load the signal -- bit of extra capacitance, possibly
> bit of
> extra R depending on the probe impedance. Of course can "shape" the signal
> --
> obviously not desirable for purposes of accurate measurement. (As a fun
> academic
> exercise, look up "observer effect" and "Heisenberg Uncertainty Principle").
>
> The effect of such shaping may reduce unwanted noise a little (good). It
> may also
> slew the signal (change rise/fall time) differently than predicted by
> high-speed
> signal simulation of your board layout (bad). Just guessing, but in your
> case, it
> might be that it slows down the data bit in question, which somehow fixes a
> marginal
> timing problem. If that were really happening, then here are some questions
> for you:
>
> -are all of your data traces (in the layout)
> equal length between the DSP and SDRAM?
>
> -do all data traces have zero-ohm Rs or none
> of them?
>
> -are some data traces connected also to
> Flash (or FPGA or other peripheral) and
> some are not?
>
> -Jeff
>
>> Second, about the EMIF setup. There is an example of the EMIF setup in
>> the C672X EMIF manual that configures the MT48LC4M16A2-75 memory
>> (which is the same one that I am using). I setup the EMIF according to
>> it. Of course I also did the calculation based on the memory datasheet
>> to verify it. So hopefully there should not be any error here. But I
>> won't rule out the possibility that it might cause my EMIF problem.
>>
>> I also reconfigured the EMIF when I tried to eliminate the problem by
>> solwing down the EMIF clock rate.
>>
>> I am varying the EMIF value like Mike said to see what will be going on.
>>
>> Best regards
>> Peter
>>
>> On 08/07/2008, Michael Dunn wrote:
>> > Hello Peter,
>> >
>> > On Sun, Jul 6, 2008 at 9:22 PM, wrote:
>> >> HI
>> >>
>> >> My system is a C6722 DSP with a Micron MT48LC4M16A2-75 SDRAM.
>> >> Everything
>> >> works fine now but some problem with the SDRAM, there are sometimes a
>> >> undesired bit (or sometimes more than one) appeared when I read the
>> >> data
>> >> from SDRAM in the CCS.
>> >>
>> >> I inputed a sine wave (1KHz) into the ADC, the dMAX then copy it into
>> >> the
>> >> internal memory. My C code then copys the data from the internal memory
>> >> into
>> >> the external memory, namely SDRAM.
>> >>
>> >> Using the CCS Graph function, I should see exactly the same sine wave
>> >> from
>> >> both internal and external memory, and I do see the same graph for most
>> >> of
>> >> the time. But sometimes there are extra bits appear only on the SDRAM
>> >> side.
>> >> So it must be somethings wrong between the DSP and SDRAM.
>> >>
>> >> By the extra bit, I mean a correct data word
>> >> 00000000000000000000000000111111 appeared as
>> >> 0000000"1"000000000000000000111111. One or more (2~3) extra bits
>> >> appeard.
>> >> It
>> >> appeared randomly but some data bits more often appear error bit than
>> >> others. The errors appeared address are random as well.
>> >>
>> >> There are two methods that I can make the error bit temporarily
>> >> disappear.
>> >> First method is keep refreshing the graph window, then error will
>> >> disappear
>> >> and the correct sine waves are shown. But sometimes it will get worst.
>> >
>> > I don't put much stock in "what this means" - it usually means
>> > that something could be wrong somewhere. Keep in mind that every time
>> > that you hit refresh on 6727 the DSP is halted. This halt appears
>> > 'some where in the execution of your code'. DMA continuing with the
>> > DSP halted, interrupts missed with the DSP halted, etc. can cause some
>> > weird side effects.
>> >>
>> >> Second method is used when the error bit won't disappear when I
>> >> refreshing
>> >> the graph window. I can hook an oscilloscope probe to the data pin that
>> >> appear the error bit, then the error bit will disappear. But when I
>> >> remove
>> >> the probe, the error bit back again.
>> >
>> >
>> > This seems to point to a timing problem.
>> >
>> > I suggest trying to piece together a deterministic example test to try
>> > to 'catch the failure'.
>> >
>> > If you don't find an obvious problem, the memory subsystem should be
>> > reviewed.
>> > ---paste from another message on the question ""But it's sure that the
>> > data after LDW is wrong, because the one in memory is still right. I
>> > just want to know if such kinds of problem is general or can only be
>> > seen very seldom? ---
>> > <>
>> > The answer for me is NEVER when the following are correct [I may have
>> > left out a few]:
>> > NOTE: TI DSPs are used in several critical applications that require
>> > 100% repeatability.
>> > 1. The experiment is performed by running the DSP [not single
>> > stepping, modifying registers, etc].
>> > 2. Program software can cause intermittent 'strange problems' [bad
>> > assembly code that works 99.9% of the time, 'C' pointer problems,
>> > arrays/buffers going beyond their allocation, incorrect algorithms
>> > that work 99% of the time, etc]
>> > 3. Voltages [checked with a scope, not a meter]. Sometimes switching
>> > power supplies are not filtered as well as you think.
>> > 4. Board design - power and ground planes, analog/digital ground
>> > separation, other good board design practices [i.e. a bad practice
>> > would be to put a switching power supply right next to the DSP or
>> > PLL].
>> > 5. Board environment - setting the board on top of a CRT monitor while
>> > running it can cause mystery problems.
>> > 6. Electrical environment - plugging the AC into an outlet that is
>> > shared with a large AC motor [which could be on the other side of the
>> > wall].
>> > 7. Board assembly - all pins/balls must be soldered [as previously
>> > mentioned]. If you take the extreme case of only 1 or 2 core voltage
>> > or ground pins soldered - everything might 'look ok most of the time'
>> > for simple stuff, but you will get 'strange behavior' that may or may
>> > not be repeatable.
>> >
>> > I have 'gotten gray hair' from scenarios similar to the above examples.
>> > --- end paste ---
>> >
>> >
>> >>
>> >> This issue makes my SDRAM unreliable. I suspect that it is caused by
>> >> the
>> >> EMI, but I am not really sure about that. Anyone have any idea what
>> >> might
>> >> be
>> >> going wrong? All suggestions are welcome. Any help would be
>> >> appreciated.
>> >>
>> >> PS. DSP @ 200MHz and EMIF @ 100MHz.
>> >> PS.. It happened when the EMIF @ 80MHz
>> >
>> > One question might be your EMIF settings. Are they correct??
>> > Trying intentionally adding +1 to your EMIF clock settings just to see
>> > what happens.
>> >
>> > mikedunn
>> >> Best regards
>> >>
>> >> Peter
> Start a New Thread

Peter,

On Wed, Jul 9, 2008 at 2:21 AM, Peter Wu wrote:
> HI
>
> Thanks for your explanation, Jeff.
> To answer Jeff's question first.
>
>> -are all of your data traces (in the layout)
>> equal length between the DSP and SDRAM?
>
> They are not equal length, the difference is less than 3cm.
>
> -do all data traces have zero-ohm Rs or none
> of them?
>
> Do you mean a zero-ohm resister on the traces or the resistance of the
> line is zero ohm?
> There is no zero-ohm resister connect to the traces, and the line
> resistance is almost 0 ohm (according to a normal multi-meter).
>
> -are some data traces connected also to
> Flash (or FPGA or other peripheral) and
> some are not?
>
> I used to connect them to a Flash memory, but I have removed it.
> There is a strange symptom happened, when I trying to move the data
> into the SDRAM.
>
> My data are 32-bit word, but I only use the lower 17 bits, the rest of
> bits are paded with zeros. When I left shift the data for 4 bits,
> which the data reach the bit 20, the problem disappeared. I have
> measured the track, but there is no connection problem, (as far as I
> can see). What does this mean? A board problem?

My *guesstimate* based on the info:

1. board assembly/solder problem [most likely]
2. ESD damaged SDRAM chip [or a gray market 'seconds' or untested device]

mikedunn
>
> Best regards
> Peter
>
> On 08/07/2008, Jeff Brower wrote:
>> Peter-
>>
>>> Mike and Jeff. Thanks for your reply.
>>>
>>> First, about the timing issue. I really don't understand that how the
>>> scope probe affects the timing. I thought there are some kind of EMI
>>> noise around the memory circuit, and the scope probe helps reduce the
>>> noise. Apparently I am overruled. Could you please explain a little
>>> bit for me.
>>
>> The scope probe can load the signal -- bit of extra capacitance, possibly
>> bit of
>> extra R depending on the probe impedance. Of course can "shape" the signal
>> --
>> obviously not desirable for purposes of accurate measurement. (As a fun
>> academic
>> exercise, look up "observer effect" and "Heisenberg Uncertainty Principle").
>>
>> The effect of such shaping may reduce unwanted noise a little (good). It
>> may also
>> slew the signal (change rise/fall time) differently than predicted by
>> high-speed
>> signal simulation of your board layout (bad). Just guessing, but in your
>> case, it
>> might be that it slows down the data bit in question, which somehow fixes a
>> marginal
>> timing problem. If that were really happening, then here are some questions
>> for you:
>>
>> -are all of your data traces (in the layout)
>> equal length between the DSP and SDRAM?
>>
>> -do all data traces have zero-ohm Rs or none
>> of them?
>>
>> -are some data traces connected also to
>> Flash (or FPGA or other peripheral) and
>> some are not?
>>
>> -Jeff
>>
>>> Second, about the EMIF setup. There is an example of the EMIF setup in
>>> the C672X EMIF manual that configures the MT48LC4M16A2-75 memory
>>> (which is the same one that I am using). I setup the EMIF according to
>>> it. Of course I also did the calculation based on the memory datasheet
>>> to verify it. So hopefully there should not be any error here. But I
>>> won't rule out the possibility that it might cause my EMIF problem.
>>>
>>> I also reconfigured the EMIF when I tried to eliminate the problem by
>>> solwing down the EMIF clock rate.
>>>
>>> I am varying the EMIF value like Mike said to see what will be going on.
>>>
>>> Best regards
>>> Peter
>>>
>>> On 08/07/2008, Michael Dunn wrote:
>>> > Hello Peter,
>>> >
>>> > On Sun, Jul 6, 2008 at 9:22 PM, wrote:
>>> >> HI
>>> >>
>>> >> My system is a C6722 DSP with a Micron MT48LC4M16A2-75 SDRAM.
>>> >> Everything
>>> >> works fine now but some problem with the SDRAM, there are sometimes a
>>> >> undesired bit (or sometimes more than one) appeared when I read the
>>> >> data
>>> >> from SDRAM in the CCS.
>>> >>
>>> >> I inputed a sine wave (1KHz) into the ADC, the dMAX then copy it into
>>> >> the
>>> >> internal memory. My C code then copys the data from the internal memory
>>> >> into
>>> >> the external memory, namely SDRAM.
>>> >>
>>> >> Using the CCS Graph function, I should see exactly the same sine wave
>>> >> from
>>> >> both internal and external memory, and I do see the same graph for most
>>> >> of
>>> >> the time. But sometimes there are extra bits appear only on the SDRAM
>>> >> side.
>>> >> So it must be somethings wrong between the DSP and SDRAM.
>>> >>
>>> >> By the extra bit, I mean a correct data word
>>> >> 00000000000000000000000000111111 appeared as
>>> >> 0000000"1"000000000000000000111111. One or more (2~3) extra bits
>>> >> appeard.
>>> >> It
>>> >> appeared randomly but some data bits more often appear error bit than
>>> >> others. The errors appeared address are random as well.
>>> >>
>>> >> There are two methods that I can make the error bit temporarily
>>> >> disappear.
>>> >> First method is keep refreshing the graph window, then error will
>>> >> disappear
>>> >> and the correct sine waves are shown. But sometimes it will get worst.
>>> >
>>> > I don't put much stock in "what this means" - it usually means
>>> > that something could be wrong somewhere. Keep in mind that every time
>>> > that you hit refresh on 6727 the DSP is halted. This halt appears
>>> > 'some where in the execution of your code'. DMA continuing with the
>>> > DSP halted, interrupts missed with the DSP halted, etc. can cause some
>>> > weird side effects.
>>> >>
>>> >> Second method is used when the error bit won't disappear when I
>>> >> refreshing
>>> >> the graph window. I can hook an oscilloscope probe to the data pin that
>>> >> appear the error bit, then the error bit will disappear. But when I
>>> >> remove
>>> >> the probe, the error bit back again.
>>> >
>>> >
>>> > This seems to point to a timing problem.
>>> >
>>> > I suggest trying to piece together a deterministic example test to try
>>> > to 'catch the failure'.
>>> >
>>> > If you don't find an obvious problem, the memory subsystem should be
>>> > reviewed.
>>> > ---paste from another message on the question ""But it's sure that the
>>> > data after LDW is wrong, because the one in memory is still right. I
>>> > just want to know if such kinds of problem is general or can only be
>>> > seen very seldom? ---
>>> > <>
>>> > The answer for me is NEVER when the following are correct [I may have
>>> > left out a few]:
>>> > NOTE: TI DSPs are used in several critical applications that require
>>> > 100% repeatability.
>>> > 1. The experiment is performed by running the DSP [not single
>>> > stepping, modifying registers, etc].
>>> > 2. Program software can cause intermittent 'strange problems' [bad
>>> > assembly code that works 99.9% of the time, 'C' pointer problems,
>>> > arrays/buffers going beyond their allocation, incorrect algorithms
>>> > that work 99% of the time, etc]
>>> > 3. Voltages [checked with a scope, not a meter]. Sometimes switching
>>> > power supplies are not filtered as well as you think.
>>> > 4. Board design - power and ground planes, analog/digital ground
>>> > separation, other good board design practices [i.e. a bad practice
>>> > would be to put a switching power supply right next to the DSP or
>>> > PLL].
>>> > 5. Board environment - setting the board on top of a CRT monitor while
>>> > running it can cause mystery problems.
>>> > 6. Electrical environment - plugging the AC into an outlet that is
>>> > shared with a large AC motor [which could be on the other side of the
>>> > wall].
>>> > 7. Board assembly - all pins/balls must be soldered [as previously
>>> > mentioned]. If you take the extreme case of only 1 or 2 core voltage
>>> > or ground pins soldered - everything might 'look ok most of the time'
>>> > for simple stuff, but you will get 'strange behavior' that may or may
>>> > not be repeatable.
>>> >
>>> > I have 'gotten gray hair' from scenarios similar to the above examples.
>>> > --- end paste ---
>>> >
>>> >
>>> >>
>>> >> This issue makes my SDRAM unreliable. I suspect that it is caused by
>>> >> the
>>> >> EMI, but I am not really sure about that. Anyone have any idea what
>>> >> might
>>> >> be
>>> >> going wrong? All suggestions are welcome. Any help would be
>>> >> appreciated.
>>> >>
>>> >> PS. DSP @ 200MHz and EMIF @ 100MHz.
>>> >> PS.. It happened when the EMIF @ 80MHz
>>> >
>>> > One question might be your EMIF settings. Are they correct??
>>> > Trying intentionally adding +1 to your EMIF clock settings just to see
>>> > what happens.
>>> >
>>> > mikedunn
>>> >> Best regards
>>> >>
>>> >> Peter
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php Start a New Thread

Peter-

> Thanks for your explanation, Jeff.
> To answer Jeff's question first.
>
> > -are all of your data traces (in the layout)
> > equal length between the DSP and SDRAM?
>
> They are not equal length, the difference is less than 3cm.

Which are the longest 3 or 4 data line traces?

> -do all data traces have zero-ohm Rs or none
> of them?
>
> Do you mean a zero-ohm resister on the traces or the resistance of the
> line is zero ohm?
> There is no zero-ohm resister connect to the traces, and the line
> resistance is almost 0 ohm (according to a normal multi-meter).

Sorry, I meant 25 or 33 ohm, not zero-ohm. Going too fast there.

So you have no series Rs between the DSP and SDRAM? Are you using 2x 16-bit SDRAMs
or 1x 32-bit SDRAM?

> -are some data traces connected also to
> Flash (or FPGA or other peripheral) and
> some are not?
>
> I used to connect them to a Flash memory, but I have removed it.

Ok, that's good.

> There is a strange symptom happened, when I trying to move the data
> into the SDRAM.
>
> My data are 32-bit word, but I only use the lower 17 bits, the rest of
> bits are paded with zeros. When I left shift the data for 4 bits,
> which the data reach the bit 20, the problem disappeared. I have
> measured the track, but there is no connection problem, (as far as I
> can see). What does this mean? A board problem?

Ok, so lots of zeros in the lower 20 bits seems to be helpful. In that case, try
some more tests. For example, try a pattern of 0x00000001 and add one more bit and
keep moving the second bit. I.e. 0x3, 0x5, 0x9, etc. If that continues to work,
then start with 0x00000002 and repeat. Try to see if there is one bit somewhere in
your lower 17 bits that is "associated" with the error.

-Jeff

> On 08/07/2008, Jeff Brower wrote:
> > Peter-
> >
> >> Mike and Jeff. Thanks for your reply.
> >>
> >> First, about the timing issue. I really don't understand that how the
> >> scope probe affects the timing. I thought there are some kind of EMI
> >> noise around the memory circuit, and the scope probe helps reduce the
> >> noise. Apparently I am overruled. Could you please explain a little
> >> bit for me.
> >
> > The scope probe can load the signal -- bit of extra capacitance, possibly
> > bit of
> > extra R depending on the probe impedance. Of course can "shape" the signal
> > --
> > obviously not desirable for purposes of accurate measurement. (As a fun
> > academic
> > exercise, look up "observer effect" and "Heisenberg Uncertainty Principle").
> >
> > The effect of such shaping may reduce unwanted noise a little (good). It
> > may also
> > slew the signal (change rise/fall time) differently than predicted by
> > high-speed
> > signal simulation of your board layout (bad). Just guessing, but in your
> > case, it
> > might be that it slows down the data bit in question, which somehow fixes a
> > marginal
> > timing problem. If that were really happening, then here are some questions
> > for you:
> >
> > -are all of your data traces (in the layout)
> > equal length between the DSP and SDRAM?
> >
> > -do all data traces have zero-ohm Rs or none
> > of them?
> >
> > -are some data traces connected also to
> > Flash (or FPGA or other peripheral) and
> > some are not?
> >
> > -Jeff
> >
> >> Second, about the EMIF setup. There is an example of the EMIF setup in
> >> the C672X EMIF manual that configures the MT48LC4M16A2-75 memory
> >> (which is the same one that I am using). I setup the EMIF according to
> >> it. Of course I also did the calculation based on the memory datasheet
> >> to verify it. So hopefully there should not be any error here. But I
> >> won't rule out the possibility that it might cause my EMIF problem.
> >>
> >> I also reconfigured the EMIF when I tried to eliminate the problem by
> >> solwing down the EMIF clock rate.
> >>
> >> I am varying the EMIF value like Mike said to see what will be going on.
> >>
> >> Best regards
> >> Peter
> >>
> >> On 08/07/2008, Michael Dunn wrote:
> >> > Hello Peter,
> >> >
> >> > On Sun, Jul 6, 2008 at 9:22 PM, wrote:
> >> >> HI
> >> >>
> >> >> My system is a C6722 DSP with a Micron MT48LC4M16A2-75 SDRAM.
> >> >> Everything
> >> >> works fine now but some problem with the SDRAM, there are sometimes a
> >> >> undesired bit (or sometimes more than one) appeared when I read the
> >> >> data
> >> >> from SDRAM in the CCS.
> >> >>
> >> >> I inputed a sine wave (1KHz) into the ADC, the dMAX then copy it into
> >> >> the
> >> >> internal memory. My C code then copys the data from the internal memory
> >> >> into
> >> >> the external memory, namely SDRAM.
> >> >>
> >> >> Using the CCS Graph function, I should see exactly the same sine wave
> >> >> from
> >> >> both internal and external memory, and I do see the same graph for most
> >> >> of
> >> >> the time. But sometimes there are extra bits appear only on the SDRAM
> >> >> side.
> >> >> So it must be somethings wrong between the DSP and SDRAM.
> >> >>
> >> >> By the extra bit, I mean a correct data word
> >> >> 00000000000000000000000000111111 appeared as
> >> >> 0000000"1"000000000000000000111111. One or more (2~3) extra bits
> >> >> appeard.
> >> >> It
> >> >> appeared randomly but some data bits more often appear error bit than
> >> >> others. The errors appeared address are random as well.
> >> >>
> >> >> There are two methods that I can make the error bit temporarily
> >> >> disappear.
> >> >> First method is keep refreshing the graph window, then error will
> >> >> disappear
> >> >> and the correct sine waves are shown. But sometimes it will get worst.
> >> >
> >> > I don't put much stock in "what this means" - it usually means
> >> > that something could be wrong somewhere. Keep in mind that every time
> >> > that you hit refresh on 6727 the DSP is halted. This halt appears
> >> > 'some where in the execution of your code'. DMA continuing with the
> >> > DSP halted, interrupts missed with the DSP halted, etc. can cause some
> >> > weird side effects.
> >> >>
> >> >> Second method is used when the error bit won't disappear when I
> >> >> refreshing
> >> >> the graph window. I can hook an oscilloscope probe to the data pin that
> >> >> appear the error bit, then the error bit will disappear. But when I
> >> >> remove
> >> >> the probe, the error bit back again.
> >> >
> >> >
> >> > This seems to point to a timing problem.
> >> >
> >> > I suggest trying to piece together a deterministic example test to try
> >> > to 'catch the failure'.
> >> >
> >> > If you don't find an obvious problem, the memory subsystem should be
> >> > reviewed.
> >> > ---paste from another message on the question ""But it's sure that the
> >> > data after LDW is wrong, because the one in memory is still right. I
> >> > just want to know if such kinds of problem is general or can only be
> >> > seen very seldom? ---
> >> > <>
> >> > The answer for me is NEVER when the following are correct [I may have
> >> > left out a few]:
> >> > NOTE: TI DSPs are used in several critical applications that require
> >> > 100% repeatability.
> >> > 1. The experiment is performed by running the DSP [not single
> >> > stepping, modifying registers, etc].
> >> > 2. Program software can cause intermittent 'strange problems' [bad
> >> > assembly code that works 99.9% of the time, 'C' pointer problems,
> >> > arrays/buffers going beyond their allocation, incorrect algorithms
> >> > that work 99% of the time, etc]
> >> > 3. Voltages [checked with a scope, not a meter]. Sometimes switching
> >> > power supplies are not filtered as well as you think.
> >> > 4. Board design - power and ground planes, analog/digital ground
> >> > separation, other good board design practices [i.e. a bad practice
> >> > would be to put a switching power supply right next to the DSP or
> >> > PLL].
> >> > 5. Board environment - setting the board on top of a CRT monitor while
> >> > running it can cause mystery problems.
> >> > 6. Electrical environment - plugging the AC into an outlet that is
> >> > shared with a large AC motor [which could be on the other side of the
> >> > wall].
> >> > 7. Board assembly - all pins/balls must be soldered [as previously
> >> > mentioned]. If you take the extreme case of only 1 or 2 core voltage
> >> > or ground pins soldered - everything might 'look ok most of the time'
> >> > for simple stuff, but you will get 'strange behavior' that may or may
> >> > not be repeatable.
> >> >
> >> > I have 'gotten gray hair' from scenarios similar to the above examples.
> >> > --- end paste ---
> >> >
> >> >
> >> >>
> >> >> This issue makes my SDRAM unreliable. I suspect that it is caused by
> >> >> the
> >> >> EMI, but I am not really sure about that. Anyone have any idea what
> >> >> might
> >> >> be
> >> >> going wrong? All suggestions are welcome. Any help would be
> >> >> appreciated.
> >> >>
> >> >> PS. DSP @ 200MHz and EMIF @ 100MHz.
> >> >> PS.. It happened when the EMIF @ 80MHz
> >> >
> >> > One question might be your EMIF settings. Are they correct??
> >> > Trying intentionally adding +1 to your EMIF clock settings just to see
> >> > what happens.
> >> >
> >> > mikedunn
> >> >> Best regards
> >> >>
> >> >> Peter
> > Start a New Thread

HI Jeff

The error bit happened to both long and short track. The longest
tracks are D3 to D7.

I don't have series Rs between the DSP and SDRAM. Should I add it?
I use one 16-bit SDRAM.

I will try the test method you said. Thanks a lot.

Best regards
Peter

On 10/07/2008, Jeff Brower wrote:
> Peter-
>
>> Thanks for your explanation, Jeff.
>> To answer Jeff's question first.
>>
>> > -are all of your data traces (in the layout)
>> > equal length between the DSP and SDRAM?
>>
>> They are not equal length, the difference is less than 3cm.
>
> Which are the longest 3 or 4 data line traces?
>
>> -do all data traces have zero-ohm Rs or none
>> of them?
>>
>> Do you mean a zero-ohm resister on the traces or the resistance of the
>> line is zero ohm?
>> There is no zero-ohm resister connect to the traces, and the line
>> resistance is almost 0 ohm (according to a normal multi-meter).
>
> Sorry, I meant 25 or 33 ohm, not zero-ohm. Going too fast there.
>
> So you have no series Rs between the DSP and SDRAM? Are you using 2x 16-bit
> SDRAMs
> or 1x 32-bit SDRAM?
>
>> -are some data traces connected also to
>> Flash (or FPGA or other peripheral) and
>> some are not?
>>
>> I used to connect them to a Flash memory, but I have removed it.
>
> Ok, that's good.
>
>> There is a strange symptom happened, when I trying to move the data
>> into the SDRAM.
>>
>> My data are 32-bit word, but I only use the lower 17 bits, the rest of
>> bits are paded with zeros. When I left shift the data for 4 bits,
>> which the data reach the bit 20, the problem disappeared. I have
>> measured the track, but there is no connection problem, (as far as I
>> can see). What does this mean? A board problem?
>
> Ok, so lots of zeros in the lower 20 bits seems to be helpful. In that
> case, try
> some more tests. For example, try a pattern of 0x00000001 and add one more
> bit and
> keep moving the second bit. I.e. 0x3, 0x5, 0x9, etc. If that continues to
> work,
> then start with 0x00000002 and repeat. Try to see if there is one bit
> somewhere in
> your lower 17 bits that is "associated" with the error.
>
> -Jeff
>
>> On 08/07/2008, Jeff Brower wrote:
>> > Peter-
>> >
>> >> Mike and Jeff. Thanks for your reply.
>> >>
>> >> First, about the timing issue. I really don't understand that how the
>> >> scope probe affects the timing. I thought there are some kind of EMI
>> >> noise around the memory circuit, and the scope probe helps reduce the
>> >> noise. Apparently I am overruled. Could you please explain a little
>> >> bit for me.
>> >
>> > The scope probe can load the signal -- bit of extra capacitance,
>> > possibly
>> > bit of
>> > extra R depending on the probe impedance. Of course can "shape" the
>> > signal
>> > --
>> > obviously not desirable for purposes of accurate measurement. (As a fun
>> > academic
>> > exercise, look up "observer effect" and "Heisenberg Uncertainty
>> > Principle").
>> >
>> > The effect of such shaping may reduce unwanted noise a little (good).
>> > It
>> > may also
>> > slew the signal (change rise/fall time) differently than predicted by
>> > high-speed
>> > signal simulation of your board layout (bad). Just guessing, but in
>> > your
>> > case, it
>> > might be that it slows down the data bit in question, which somehow
>> > fixes a
>> > marginal
>> > timing problem. If that were really happening, then here are some
>> > questions
>> > for you:
>> >
>> > -are all of your data traces (in the layout)
>> > equal length between the DSP and SDRAM?
>> >
>> > -do all data traces have zero-ohm Rs or none
>> > of them?
>> >
>> > -are some data traces connected also to
>> > Flash (or FPGA or other peripheral) and
>> > some are not?
>> >
>> > -Jeff
>> >
>> >> Second, about the EMIF setup. There is an example of the EMIF setup in
>> >> the C672X EMIF manual that configures the MT48LC4M16A2-75 memory
>> >> (which is the same one that I am using). I setup the EMIF according to
>> >> it. Of course I also did the calculation based on the memory datasheet
>> >> to verify it. So hopefully there should not be any error here. But I
>> >> won't rule out the possibility that it might cause my EMIF problem.
>> >>
>> >> I also reconfigured the EMIF when I tried to eliminate the problem by
>> >> solwing down the EMIF clock rate.
>> >>
>> >> I am varying the EMIF value like Mike said to see what will be going
>> >> on.
>> >>
>> >> Best regards
>> >> Peter
>> >>
>> >> On 08/07/2008, Michael Dunn wrote:
>> >> > Hello Peter,
>> >> >
>> >> > On Sun, Jul 6, 2008 at 9:22 PM, wrote:
>> >> >> HI
>> >> >>
>> >> >> My system is a C6722 DSP with a Micron MT48LC4M16A2-75 SDRAM.
>> >> >> Everything
>> >> >> works fine now but some problem with the SDRAM, there are sometimes
>> >> >> a
>> >> >> undesired bit (or sometimes more than one) appeared when I read the
>> >> >> data
>> >> >> from SDRAM in the CCS.
>> >> >>
>> >> >> I inputed a sine wave (1KHz) into the ADC, the dMAX then copy it
>> >> >> into
>> >> >> the
>> >> >> internal memory. My C code then copys the data from the internal
>> >> >> memory
>> >> >> into
>> >> >> the external memory, namely SDRAM.
>> >> >>
>> >> >> Using the CCS Graph function, I should see exactly the same sine
>> >> >> wave
>> >> >> from
>> >> >> both internal and external memory, and I do see the same graph for
>> >> >> most
>> >> >> of
>> >> >> the time. But sometimes there are extra bits appear only on the
>> >> >> SDRAM
>> >> >> side.
>> >> >> So it must be somethings wrong between the DSP and SDRAM.
>> >> >>
>> >> >> By the extra bit, I mean a correct data word
>> >> >> 00000000000000000000000000111111 appeared as
>> >> >> 0000000"1"000000000000000000111111. One or more (2~3) extra bits
>> >> >> appeard.
>> >> >> It
>> >> >> appeared randomly but some data bits more often appear error bit
>> >> >> than
>> >> >> others. The errors appeared address are random as well.
>> >> >>
>> >> >> There are two methods that I can make the error bit temporarily
>> >> >> disappear.
>> >> >> First method is keep refreshing the graph window, then error will
>> >> >> disappear
>> >> >> and the correct sine waves are shown. But sometimes it will get
>> >> >> worst.
>> >> >
>> >> > I don't put much stock in "what this means" - it usually means
>> >> > that something could be wrong somewhere. Keep in mind that every time
>> >> > that you hit refresh on 6727 the DSP is halted. This halt appears
>> >> > 'some where in the execution of your code'. DMA continuing with the
>> >> > DSP halted, interrupts missed with the DSP halted, etc. can cause
>> >> > some
>> >> > weird side effects.
>> >> >>
>> >> >> Second method is used when the error bit won't disappear when I
>> >> >> refreshing
>> >> >> the graph window. I can hook an oscilloscope probe to the data pin
>> >> >> that
>> >> >> appear the error bit, then the error bit will disappear. But when I
>> >> >> remove
>> >> >> the probe, the error bit back again.
>> >> >
>> >> >
>> >> > This seems to point to a timing problem.
>> >> >
>> >> > I suggest trying to piece together a deterministic example test to
>> >> > try
>> >> > to 'catch the failure'.
>> >> >
>> >> > If you don't find an obvious problem, the memory subsystem should be
>> >> > reviewed.
>> >> > ---paste from another message on the question ""But it's sure that
>> >> > the
>> >> > data after LDW is wrong, because the one in memory is still right. I
>> >> > just want to know if such kinds of problem is general or can only be
>> >> > seen very seldom? ---
>> >> > <>
>> >> > The answer for me is NEVER when the following are correct [I may have
>> >> > left out a few]:
>> >> > NOTE: TI DSPs are used in several critical applications that require
>> >> > 100% repeatability.
>> >> > 1. The experiment is performed by running the DSP [not single
>> >> > stepping, modifying registers, etc].
>> >> > 2. Program software can cause intermittent 'strange problems' [bad
>> >> > assembly code that works 99.9% of the time, 'C' pointer problems,
>> >> > arrays/buffers going beyond their allocation, incorrect algorithms
>> >> > that work 99% of the time, etc]
>> >> > 3. Voltages [checked with a scope, not a meter]. Sometimes switching
>> >> > power supplies are not filtered as well as you think.
>> >> > 4. Board design - power and ground planes, analog/digital ground
>> >> > separation, other good board design practices [i.e. a bad practice
>> >> > would be to put a switching power supply right next to the DSP or
>> >> > PLL].
>> >> > 5. Board environment - setting the board on top of a CRT monitor
>> >> > while
>> >> > running it can cause mystery problems.
>> >> > 6. Electrical environment - plugging the AC into an outlet that is
>> >> > shared with a large AC motor [which could be on the other side of the
>> >> > wall].
>> >> > 7. Board assembly - all pins/balls must be soldered [as previously
>> >> > mentioned]. If you take the extreme case of only 1 or 2 core voltage
>> >> > or ground pins soldered - everything might 'look ok most of the time'
>> >> > for simple stuff, but you will get 'strange behavior' that may or may
>> >> > not be repeatable.
>> >> >
>> >> > I have 'gotten gray hair' from scenarios similar to the above
>> >> > examples.
>> >> > --- end paste ---
>> >> >
>> >> >
>> >> >>
>> >> >> This issue makes my SDRAM unreliable. I suspect that it is caused by
>> >> >> the
>> >> >> EMI, but I am not really sure about that. Anyone have any idea what
>> >> >> might
>> >> >> be
>> >> >> going wrong? All suggestions are welcome. Any help would be
>> >> >> appreciated.
>> >> >>
>> >> >> PS. DSP @ 200MHz and EMIF @ 100MHz.
>> >> >> PS.. It happened when the EMIF @ 80MHz
>> >> >
>> >> > One question might be your EMIF settings. Are they correct??
>> >> > Trying intentionally adding +1 to your EMIF clock settings just to
>> >> > see
>> >> > what happens.
>> >> >
>> >> > mikedunn
>> >> >> Best regards
>> >> >>
>> >> >> Peter
>> >
>> Start a New Thread

Peter-

> The error bit happened to both long and short track. The longest
> tracks are D3 to D7.

Ok.

> I don't have series Rs between the DSP and SDRAM. Should I add it?
> I use one 16-bit SDRAM.

Wait a minute... If you use 16-bit wide SDRAM, and you are writing 32-bit words, does this mean the C6722 makes two
(2) 16-bit accesses for each word read/write? What if you make only 16-bit read/writes?

I haven't used the C6722 yet so I'm not sure about this. But maybe experimenting with 16-bit accesses might give you
some clue. If physical access is only 16-bits wide, then it would not make sense for you to see no errors in the
lower 16 bits, and some bit errors in the "upper" 16 bits... For example, if there was really a physical bit/trace
problem, say on bit 2, then it should also appear on bit 18.

-Jeff

> I will try the test method you said. Thanks a lot.
>
> Best regards
> Peter
>
> On 10/07/2008, Jeff Brower wrote:
>> Peter-
>>
>>> Thanks for your explanation, Jeff.
>>> To answer Jeff's question first.
>>>
>>> > -are all of your data traces (in the layout)
>>> > equal length between the DSP and SDRAM?
>>>
>>> They are not equal length, the difference is less than 3cm.
>>
>> Which are the longest 3 or 4 data line traces?
>>
>>> -do all data traces have zero-ohm Rs or none
>>> of them?
>>>
>>> Do you mean a zero-ohm resister on the traces or the resistance of the
>>> line is zero ohm?
>>> There is no zero-ohm resister connect to the traces, and the line
>>> resistance is almost 0 ohm (according to a normal multi-meter).
>>
>> Sorry, I meant 25 or 33 ohm, not zero-ohm. Going too fast there.
>>
>> So you have no series Rs between the DSP and SDRAM? Are you using 2x 16-bit
>> SDRAMs
>> or 1x 32-bit SDRAM?
>>
>>> -are some data traces connected also to
>>> Flash (or FPGA or other peripheral) and
>>> some are not?
>>>
>>> I used to connect them to a Flash memory, but I have removed it.
>>
>> Ok, that's good.
>>
>>> There is a strange symptom happened, when I trying to move the data
>>> into the SDRAM.
>>>
>>> My data are 32-bit word, but I only use the lower 17 bits, the rest of
>>> bits are paded with zeros. When I left shift the data for 4 bits,
>>> which the data reach the bit 20, the problem disappeared. I have
>>> measured the track, but there is no connection problem, (as far as I
>>> can see). What does this mean? A board problem?
>>
>> Ok, so lots of zeros in the lower 20 bits seems to be helpful. In that
>> case, try
>> some more tests. For example, try a pattern of 0x00000001 and add one more
>> bit and
>> keep moving the second bit. I.e. 0x3, 0x5, 0x9, etc. If that continues to
>> work,
>> then start with 0x00000002 and repeat. Try to see if there is one bit
>> somewhere in
>> your lower 17 bits that is "associated" with the error.
>>
>> -Jeff
>>
>>> On 08/07/2008, Jeff Brower wrote:
>>> > Peter-
>>> >
>>> >> Mike and Jeff. Thanks for your reply.
>>> >>
>>> >> First, about the timing issue. I really don't understand that how the
>>> >> scope probe affects the timing. I thought there are some kind of EMI
>>> >> noise around the memory circuit, and the scope probe helps reduce the
>>> >> noise. Apparently I am overruled. Could you please explain a little
>>> >> bit for me.
>>> >
>>> > The scope probe can load the signal -- bit of extra capacitance,
>>> > possibly
>>> > bit of
>>> > extra R depending on the probe impedance. Of course can "shape" the
>>> > signal
>>> > --
>>> > obviously not desirable for purposes of accurate measurement. (As a fun
>>> > academic
>>> > exercise, look up "observer effect" and "Heisenberg Uncertainty
>>> > Principle").
>>> >
>>> > The effect of such shaping may reduce unwanted noise a little (good).
>>> > It
>>> > may also
>>> > slew the signal (change rise/fall time) differently than predicted by
>>> > high-speed
>>> > signal simulation of your board layout (bad). Just guessing, but in
>>> > your
>>> > case, it
>>> > might be that it slows down the data bit in question, which somehow
>>> > fixes a
>>> > marginal
>>> > timing problem. If that were really happening, then here are some
>>> > questions
>>> > for you:
>>> >
>>> > -are all of your data traces (in the layout)
>>> > equal length between the DSP and SDRAM?
>>> >
>>> > -do all data traces have zero-ohm Rs or none
>>> > of them?
>>> >
>>> > -are some data traces connected also to
>>> > Flash (or FPGA or other peripheral) and
>>> > some are not?
>>> >
>>> > -Jeff
>>> >
>>> >> Second, about the EMIF setup. There is an example of the EMIF setup in
>>> >> the C672X EMIF manual that configures the MT48LC4M16A2-75 memory
>>> >> (which is the same one that I am using). I setup the EMIF according to
>>> >> it. Of course I also did the calculation based on the memory datasheet
>>> >> to verify it. So hopefully there should not be any error here. But I
>>> >> won't rule out the possibility that it might cause my EMIF problem.
>>> >>
>>> >> I also reconfigured the EMIF when I tried to eliminate the problem by
>>> >> solwing down the EMIF clock rate.
>>> >>
>>> >> I am varying the EMIF value like Mike said to see what will be going
>>> >> on.
>>> >>
>>> >> Best regards
>>> >> Peter
>>> >>
>>> >> On 08/07/2008, Michael Dunn wrote:
>>> >> > Hello Peter,
>>> >> >
>>> >> > On Sun, Jul 6, 2008 at 9:22 PM, wrote:
>>> >> >> HI
>>> >> >>
>>> >> >> My system is a C6722 DSP with a Micron MT48LC4M16A2-75 SDRAM.
>>> >> >> Everything
>>> >> >> works fine now but some problem with the SDRAM, there are sometimes
>>> >> >> a
>>> >> >> undesired bit (or sometimes more than one) appeared when I read the
>>> >> >> data
>>> >> >> from SDRAM in the CCS.
>>> >> >>
>>> >> >> I inputed a sine wave (1KHz) into the ADC, the dMAX then copy it
>>> >> >> into
>>> >> >> the
>>> >> >> internal memory. My C code then copys the data from the internal
>>> >> >> memory
>>> >> >> into
>>> >> >> the external memory, namely SDRAM.
>>> >> >>
>>> >> >> Using the CCS Graph function, I should see exactly the same sine
>>> >> >> wave
>>> >> >> from
>>> >> >> both internal and external memory, and I do see the same graph for
>>> >> >> most
>>> >> >> of
>>> >> >> the time. But sometimes there are extra bits appear only on the
>>> >> >> SDRAM
>>> >> >> side.
>>> >> >> So it must be somethings wrong between the DSP and SDRAM.
>>> >> >>
>>> >> >> By the extra bit, I mean a correct data word
>>> >> >> 00000000000000000000000000111111 appeared as
>>> >> >> 0000000"1"000000000000000000111111. One or more (2~3) extra bits
>>> >> >> appeard.
>>> >> >> It
>>> >> >> appeared randomly but some data bits more often appear error bit
>>> >> >> than
>>> >> >> others. The errors appeared address are random as well.
>>> >> >>
>>> >> >> There are two methods that I can make the error bit temporarily
>>> >> >> disappear.
>>> >> >> First method is keep refreshing the graph window, then error will
>>> >> >> disappear
>>> >> >> and the correct sine waves are shown. But sometimes it will get
>>> >> >> worst.
>>> >> >
>>> >> > I don't put much stock in "what this means" - it usually means
>>> >> > that something could be wrong somewhere. Keep in mind that every time
>>> >> > that you hit refresh on 6727 the DSP is halted. This halt appears
>>> >> > 'some where in the execution of your code'. DMA continuing with the
>>> >> > DSP halted, interrupts missed with the DSP halted, etc. can cause
>>> >> > some
>>> >> > weird side effects.
>>> >> >>
>>> >> >> Second method is used when the error bit won't disappear when I
>>> >> >> refreshing
>>> >> >> the graph window. I can hook an oscilloscope probe to the data pin
>>> >> >> that
>>> >> >> appear the error bit, then the error bit will disappear. But when I
>>> >> >> remove
>>> >> >> the probe, the error bit back again.
>>> >> >
>>> >> >
>>> >> > This seems to point to a timing problem.
>>> >> >
>>> >> > I suggest trying to piece together a deterministic example test to
>>> >> > try
>>> >> > to 'catch the failure'.
>>> >> >
>>> >> > If you don't find an obvious problem, the memory subsystem should be
>>> >> > reviewed.
>>> >> > ---paste from another message on the question ""But it's sure that
>>> >> > the
>>> >> > data after LDW is wrong, because the one in memory is still right. I
>>> >> > just want to know if such kinds of problem is general or can only be
>>> >> > seen very seldom? ---
>>> >> > <>
>>> >> > The answer for me is NEVER when the following are correct [I may have
>>> >> > left out a few]:
>>> >> > NOTE: TI DSPs are used in several critical applications that require
>>> >> > 100% repeatability.
>>> >> > 1. The experiment is performed by running the DSP [not single
>>> >> > stepping, modifying registers, etc].
>>> >> > 2. Program software can cause intermittent 'strange problems' [bad
>>> >> > assembly code that works 99.9% of the time, 'C' pointer problems,
>>> >> > arrays/buffers going beyond their allocation, incorrect algorithms
>>> >> > that work 99% of the time, etc]
>>> >> > 3. Voltages [checked with a scope, not a meter]. Sometimes switching
>>> >> > power supplies are not filtered as well as you think.
>>> >> > 4. Board design - power and ground planes, analog/digital ground
>>> >> > separation, other good board design practices [i.e. a bad practice
>>> >> > would be to put a switching power supply right next to the DSP or
>>> >> > PLL].
>>> >> > 5. Board environment - setting the board on top of a CRT monitor
>>> >> > while
>>> >> > running it can cause mystery problems.
>>> >> > 6. Electrical environment - plugging the AC into an outlet that is
>>> >> > shared with a large AC motor [which could be on the other side of the
>>> >> > wall].
>>> >> > 7. Board assembly - all pins/balls must be soldered [as previously
>>> >> > mentioned]. If you take the extreme case of only 1 or 2 core voltage
>>> >> > or ground pins soldered - everything might 'look ok most of the time'
>>> >> > for simple stuff, but you will get 'strange behavior' that may or may
>>> >> > not be repeatable.
>>> >> >
>>> >> > I have 'gotten gray hair' from scenarios similar to the above
>>> >> > examples.
>>> >> > --- end paste ---
>>> >> >
>>> >> >
>>> >> >>
>>> >> >> This issue makes my SDRAM unreliable. I suspect that it is caused by
>>> >> >> the
>>> >> >> EMI, but I am not really sure about that. Anyone have any idea what
>>> >> >> might
>>> >> >> be
>>> >> >> going wrong? All suggestions are welcome. Any help would be
>>> >> >> appreciated.
>>> >> >>
>>> >> >> PS. DSP @ 200MHz and EMIF @ 100MHz.
>>> >> >> PS.. It happened when the EMIF @ 80MHz
>>> >> >
>>> >> > One question might be your EMIF settings. Are they correct??
>>> >> > Trying intentionally adding +1 to your EMIF clock settings just to
>>> >> > see
>>> >> > what happens.
>>> >> >
>>> >> > mikedunn
>>> >> >> Best regards
>>> >> >>
>>> >> >> Peter
>>> >
>>>
>>>
>>>
>>> Start a New Thread