> I am new on this area, so the next question might
sound silly. "High
> speed signal simulation" do you mean to layout the board then use
> software to simulate the signal integrity?
Yes, using layout info and IBIS models provided by device manufacturers.
Depending
on results, layout, component values, and the design itself may need to be
modified.
> and which software do you use to achieve that?
Examples include SigXplorer (Cadence) and HyperLynx (Mentor).
> You suggest to use the 25-Ohm resister. Is it because
the impedance
> matching the DSP-SDRAM? or anyother reason?
Typically lower series R values are preferred, especially as signal levels
decrease
(e.g. DDR2). My experience has been that if 50 ohm or higher is needed to get
the
circuit to work, then there may be other issues.
-Jeff
> On 21/07/2008, Jeff Brower
wrote:
>> Peter-
>>
>>> Jeff, Mike. The problem solved. I add two series resisters 39-ohms to
>>> the bit 8 and 9 tracks, which are the most of the error accrued, then
>>> the error bits disappeared.
>>
>> Glad to hear that you're back on track. You might want to use 25 ohm
series
>> R, and you might consider using small
>> R-packs so that all data lines are included.
>>
>>> So my problem should be the transmition line unmatched impedance
>>> reflect the signal. I always thought this only happenes to really high
>>> frequency such GHz. But I guess I need to put the attention to MHz as
>>> well.
>>
>> Normally for a DSP-SDRAM interface a high speed signal simulation is done
>> prior to layout. If traces are kept very
>> short you have single device loading, then you should be able to avoid
>> series Rs. But it's always a tough call.
>>
>> -Jeff
>>
>>> On 20/07/2008, Peter Wu wrote:
>>>> Hi
>>>>
>>>> Thanks for your suggestions, Jeff and Mike.
>>>>
>>>> That's really a good idea. So I change my dMAX to transfer 16bit to
>>>> external RAM instead of 32bit. But the result still the same, the
>>>> output still has some extra bits.
>>>>
>>>> I am using a test code which only receives ADC samples, then transfer
>>>> them to SDRAM by dMAX. So there is no code directly performing
>>>> anything to the received data. The interference from the code is
>>>> minimized.
>>>>
>>>> Therefore, it's down to Timing or the board design. I have checked
and
>>>> rechecked the EMIF timing. Hopefully there is no problem.
>>>>
>>>> The board design, if I add some 33 or 25 Ohms resisters to the track,
>>>> will it improve the situation?
>>>>
>>>> Best regards
>>>> Peter
>>>>
>>>> On 17/07/2008, Michael Dunn wrote:
>>>>> Peter,
>>>>>
>>>>> On Wed, Jul 16, 2008 at 8:54 PM, Jeff Brower
>>>>> wrote:
>>>>>> 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.
>>>>>
>>>>> Good catch Jeff - I also missed the 16 bit data bus - that makes a
>>>>> huge difference. This brings us back to a possible EMIF timing/setup
>>>>> issue.
>>>>> Like Jeff indicated, if you can create a scenario/test program that
>>>>> only performs 16 bit accesses, you might not see the problem. Do you
>>>>> know if your code generates any LDDW instructions?? [64 bit read]
>>>>> I would go over all of the SDRAM EMIF settings to see if they match the
>>>>> SDRAM.
>>>>> You might also create a simple 'forever loop' that runs in
internal
>>>>> memory and only performs a single 16 bit read from SDRAM each pass and
>>>>> check it on a scope. Then try it will a 32 bit read.
>>>>>
>>>>> mikedunn
>>>>>>
>>>>>> -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
>>
>
Reply by Peter Wu●July 21, 20082008-07-21
HI Jeff
I am new on this area, so the next question might sound silly. "High
speed signal simulation" do you mean to layout the board then use
software to simulate the signal integrity? and which software do you
use to achieve that?
You suggest to use the 25-Ohm resister. Is it because the impedance
matching the DSP-SDRAM? or anyother reason?
Best regards
Peter
On 21/07/2008, Jeff Brower wrote: > Peter-
>
>> Jeff, Mike. The problem solved. I add two series resisters 39-ohms to
>> the bit 8 and 9 tracks, which are the most of the error accrued, then
>> the error bits disappeared.
>
> Glad to hear that you're back on track. You might want to use 25 ohm
series
> R, and you might consider using small
> R-packs so that all data lines are included.
>
>> So my problem should be the transmition line unmatched impedance
>> reflect the signal. I always thought this only happenes to really high
>> frequency such GHz. But I guess I need to put the attention to MHz as
>> well.
>
> Normally for a DSP-SDRAM interface a high speed signal simulation is done
> prior to layout. If traces are kept very
> short you have single device loading, then you should be able to avoid
> series Rs. But it's always a tough call.
>
> -Jeff
>
>> On 20/07/2008, Peter Wu wrote:
>>> Hi
>>>
>>> Thanks for your suggestions, Jeff and Mike.
>>>
>>> That's really a good idea. So I change my dMAX to transfer 16bit to
>>> external RAM instead of 32bit. But the result still the same, the
>>> output still has some extra bits.
>>>
>>> I am using a test code which only receives ADC samples, then transfer
>>> them to SDRAM by dMAX. So there is no code directly performing
>>> anything to the received data. The interference from the code is
>>> minimized.
>>>
>>> Therefore, it's down to Timing or the board design. I have checked
and
>>> rechecked the EMIF timing. Hopefully there is no problem.
>>>
>>> The board design, if I add some 33 or 25 Ohms resisters to the track,
>>> will it improve the situation?
>>>
>>> Best regards
>>> Peter
>>>
>>> On 17/07/2008, Michael Dunn wrote:
>>>> Peter,
>>>>
>>>> On Wed, Jul 16, 2008 at 8:54 PM, Jeff Brower
>>>> wrote:
>>>>> 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.
>>>>
>>>> Good catch Jeff - I also missed the 16 bit data bus - that makes a
>>>> huge difference. This brings us back to a possible EMIF timing/setup
>>>> issue.
>>>> Like Jeff indicated, if you can create a scenario/test program that
>>>> only performs 16 bit accesses, you might not see the problem. Do you
>>>> know if your code generates any LDDW instructions?? [64 bit read]
>>>> I would go over all of the SDRAM EMIF settings to see if they match the
>>>> SDRAM.
>>>> You might also create a simple 'forever loop' that runs in
internal
>>>> memory and only performs a single 16 bit read from SDRAM each pass and
>>>> check it on a scope. Then try it will a 32 bit read.
>>>>
>>>> mikedunn
>>>>>
>>>>> -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
Reply by Jeff Brower●July 21, 20082008-07-21
Peter-
> Jeff, Mike. The problem solved. I add two series
resisters 39-ohms to
> the bit 8 and 9 tracks, which are the most of the error accrued, then
> the error bits disappeared.
Glad to hear that you're back on track. You might want to use 25 ohm
series R, and you might consider using small
R-packs so that all data lines are included.
> So my problem should be the transmition line
unmatched impedance
> reflect the signal. I always thought this only happenes to really high
> frequency such GHz. But I guess I need to put the attention to MHz as
> well.
Normally for a DSP-SDRAM interface a high speed signal simulation is done prior
to layout. If traces are kept very
short you have single device loading, then you should be able to avoid series
Rs. But it's always a tough call.
-Jeff
> On 20/07/2008, Peter Wu wrote:
>> Hi
>>
>> Thanks for your suggestions, Jeff and Mike.
>>
>> That's really a good idea. So I change my dMAX to transfer 16bit to
>> external RAM instead of 32bit. But the result still the same, the
>> output still has some extra bits.
>>
>> I am using a test code which only receives ADC samples, then transfer
>> them to SDRAM by dMAX. So there is no code directly performing
>> anything to the received data. The interference from the code is
>> minimized.
>>
>> Therefore, it's down to Timing or the board design. I have checked
and
>> rechecked the EMIF timing. Hopefully there is no problem.
>>
>> The board design, if I add some 33 or 25 Ohms resisters to the track,
>> will it improve the situation?
>>
>> Best regards
>> Peter
>>
>> On 17/07/2008, Michael Dunn wrote:
>>> Peter,
>>>
>>> On Wed, Jul 16, 2008 at 8:54 PM, Jeff Brower
>>> wrote:
>>>> 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.
>>>
>>> Good catch Jeff - I also missed the 16 bit data bus - that makes a
>>> huge difference. This brings us back to a possible EMIF timing/setup
>>> issue.
>>> Like Jeff indicated, if you can create a scenario/test program that
>>> only performs 16 bit accesses, you might not see the problem. Do you
>>> know if your code generates any LDDW instructions?? [64 bit read]
>>> I would go over all of the SDRAM EMIF settings to see if they match the
>>> SDRAM.
>>> You might also create a simple 'forever loop' that runs in
internal
>>> memory and only performs a single 16 bit read from SDRAM each pass and
>>> check it on a scope. Then try it will a 32 bit read.
>>>
>>> mikedunn
>>>>
>>>> -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
Reply by Peter Wu●July 21, 20082008-07-21
Hi
Jeff, Mike. The problem solved. I add two series resisters 39-ohms to
the bit 8 and 9 tracks, which are the most of the error accrued, then
the error bits disappeared.
So my problem should be the transmition line unmatched impedance
reflect the signal. I always thought this only happenes to really high
frequency such GHz. But I guess I need to put the attention to MHz as
well.
Thanks for all of your helps. I really really appreciate.
Best regards
Peter
On 20/07/2008, Peter Wu wrote: > Hi
>
> Thanks for your suggestions, Jeff and Mike.
>
> That's really a good idea. So I change my dMAX to transfer 16bit to
> external RAM instead of 32bit. But the result still the same, the
> output still has some extra bits.
>
> I am using a test code which only receives ADC samples, then transfer
> them to SDRAM by dMAX. So there is no code directly performing
> anything to the received data. The interference from the code is
> minimized.
>
> Therefore, it's down to Timing or the board design. I have checked and
> rechecked the EMIF timing. Hopefully there is no problem.
>
> The board design, if I add some 33 or 25 Ohms resisters to the track,
> will it improve the situation?
>
> Best regards
> Peter
>
> On 17/07/2008, Michael Dunn wrote:
>> Peter,
>>
>> On Wed, Jul 16, 2008 at 8:54 PM, Jeff Brower
>> wrote:
>>> 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.
>>
>> Good catch Jeff - I also missed the 16 bit data bus - that makes a
>> huge difference. This brings us back to a possible EMIF timing/setup
>> issue.
>> Like Jeff indicated, if you can create a scenario/test program that
>> only performs 16 bit accesses, you might not see the problem. Do you
>> know if your code generates any LDDW instructions?? [64 bit read]
>> I would go over all of the SDRAM EMIF settings to see if they match the
>> SDRAM.
>> You might also create a simple 'forever loop' that runs in
internal
>> memory and only performs a single 16 bit read from SDRAM each pass and
>> check it on a scope. Then try it will a 32 bit read.
>>
>> mikedunn
>>>
>>> -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
>>>>>> >
>>>>>>
Reply by Peter Wu●July 21, 20082008-07-21
Hi
Thanks for your suggestions, Jeff and Mike.
That's really a good idea. So I change my dMAX to transfer 16bit to
external RAM instead of 32bit. But the result still the same, the
output still has some extra bits.
I am using a test code which only receives ADC samples, then transfer
them to SDRAM by dMAX. So there is no code directly performing
anything to the received data. The interference from the code is
minimized.
Therefore, it's down to Timing or the board design. I have checked and
rechecked the EMIF timing. Hopefully there is no problem.
The board design, if I add some 33 or 25 Ohms resisters to the track,
will it improve the situation?
Best regards
Peter
On 17/07/2008, Michael Dunn wrote: > Peter,
>
> On Wed, Jul 16, 2008 at 8:54 PM, Jeff Brower wrote:
>> 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.
>
> Good catch Jeff - I also missed the 16 bit data bus - that makes a
> huge difference. This brings us back to a possible EMIF timing/setup
> issue.
> Like Jeff indicated, if you can create a scenario/test program that
> only performs 16 bit accesses, you might not see the problem. Do you
> know if your code generates any LDDW instructions?? [64 bit read]
> I would go over all of the SDRAM EMIF settings to see if they match the
> SDRAM.
> You might also create a simple 'forever loop' that runs in
internal
> memory and only performs a single 16 bit read from SDRAM each pass and
> check it on a scope. Then try it will a 32 bit read.
>
> mikedunn
>>
>> -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
>>>>> >
Reply by Michael Dunn●July 17, 20082008-07-17
Peter,
On Wed, Jul 16, 2008 at 8:54 PM, Jeff Brower wrote: > 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.
Good catch Jeff - I also missed the 16 bit data bus - that makes a
huge difference. This brings us back to a possible EMIF timing/setup
issue.
Like Jeff indicated, if you can create a scenario/test program that
only performs 16 bit accesses, you might not see the problem. Do you
know if your code generates any LDDW instructions?? [64 bit read]
I would go over all of the SDRAM EMIF settings to see if they match the
SDRAM.
You might also create a simple 'forever loop' that runs in internal
memory and only performs a single 16 bit read from SDRAM each pass and
check it on a scope. Then try it will a 32 bit read.
mikedunn >
> -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
>>>> >
>>>>
>>>>
>>>>
>>>>
Reply by Jeff Brower●July 17, 20082008-07-17
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
>>> >
>>>
>>>
>>>
>>>
Reply by Peter Wu●July 10, 20082008-07-10
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
>> >
>>
Reply by Jeff Brower●July 10, 20082008-07-10
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
> >
Reply by Michael Dunn●July 9, 20082008-07-09
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