Hi ,
I cudnt resolve or rather identify the problem associated with L2
corruption .
In the board thr are 5 DSPs , rest 4 are working fine with same application
code . This problem is faced in only one . One more strange thing observed
was , when L2 is changed , contents of DDR Memory associated with the same
DSP is also getting changed . DDR Memory have some static data .
Thanks for all the support to everyone.

regards
Jai
On 6/22/07, Jeff Brower wrote:
>
> Jai-
>
> > Even initially i had the same doubt , but verified the text area
> before
> > execution . Its the same with OK case text area. After execution memory
> is
> > getting changed .
>
> Is the same area changed? If so then try placing a breakpoint on the
> first location of that area being modified, then
> when the breakpoint occurs take a look at execution history and see the
> code was before it jumped the tracks.
>
> -Jeff
>
> > On 6/21/07, Jeff Brower wrote:
> >>
> >> Jai-
> >>
> >> > I have a strange problem . I am running an application on 6482
> with
> >> .text
> >> > in L2 Memory. Its runs successfully 98% times . Very rarely ,after
> reset
> >> if
> >> > i reload the image and run it goes to sys_halt state.
> >> > After comparing text area in L2 for success case and failure case ,
> i
> >> found
> >> > some text area is different . Those memory locations are from rts
> >> library .
> >> > Also used hardware breakpoint to monitor if some code is writing
> into
> >> code
> >> > area , but nothing happened .Can anyone help me , what could be wrong
> >> here.
> >>
> >> Did you compare the text (code) areas immediately after downloading,
> >> before any code
> >> runs? Maybe the download (I assume you are using JTAG) is not
> reliable.
> >>
> >> -Jeff
> >>
> >

Jai-
> I cudnt resolve or rather identify the problem associated with L2 corruption .In
> the board thr are 5 DSPs , rest 4 are working fine with same application code .
> This problem is faced in only one . One more strange thing observed was , when L2
> is changed , contents of DDR Memory associated with the same DSP is also getting
> changed . DDR Memory have some static data . Thanks for all the support to
> everyone.

If you have five (5) 6482s on one card, then you basically have 5 6455s at 1 GHz and
that's going to be one hot card. My first guess is the 5th DSP may be suffering from
some type heat related problem. Other guesses:

-five is an odd number; is the card doing something
like one group of 2 DSPs shares clocks (or power)
separate from other group of 3?

-last DSP is farther from clock source and clock
is not clean

-last DSP is farther from Vcc core or Vcc Mem source,
and there are Vcc ripple violations

-PLL multiplier is somehow different on the last
DSP, so it's running too slow or too fast

-some difference in DDR mem interface for last
DSP -- longer traces? pull-down/pull-up Rs
not populated the same

Questions:

1) Do you have any way to measure heat? We use simple infrared-based detectors,
available at Home Depot (or your equivalent in Bangalore).

2) How big is your card? What is the spacing between 6482s? Where are the DDR mems
located, next to each DSP? Opposite side of the card from the DSPs?

-Jeff
> On 6/22/07, Jeff Brower wrote:
>
> Jai-
>
> > Even initially i had the same doubt , but verified the text area
> before
> > execution . Its the same with OK case text area. After execution memory
> is
> > getting changed .
>
> Is the same area changed? If so then try placing a breakpoint on the
> first location of that area being modified, then
> when the breakpoint occurs take a look at execution history and see the
> code was before it jumped the tracks.
>
> -Jeff
>
> > On 6/21/07, Jeff Brower wrote:
> >>
> >> Jai-
> >>
> >> > I have a strange problem . I am running an application on 6482
> with
> >> .text
> >> > in L2 Memory. Its runs successfully 98% times . Very rarely ,after
> reset
> >> if
> >> > i reload the image and run it goes to sys_halt state.
> >> > After comparing text area in L2 for success case and failure case
> , i
> >> found
> >> > some text area is different . Those memory locations are from rts
> >> library .
> >> > Also used hardware breakpoint to monitor if some code is writing
> into
> >> code
> >> > area , but nothing happened .Can anyone help me , what could be
> wrong
> >> here.
> >>
> >> Did you compare the text (code) areas immediately after downloading,
> >> before any code
> >> runs? Maybe the download (I assume you are using JTAG) is not
> reliable.
> >>
> >> -Jeff
> >>
> >

jai,

The most common problem is using un-initialized memory, especially a pointer that does not contain a
valid value.

I would be looking at missing initialization sequence, at off-by-one error, invalid subscript value,
etc.

R. Williams

---------- Original Message -----------
From: j...@gmail.com
To: c...
Sent: Thu, 21 Jun 2007 10:44:25 -0400
Subject: [c6x] Program memory corruption in L2

> Hi ,
> I have a strange problem . I am running an application on 6482 with .text in L2 Memory.
> Its runs successfully 98% times . Very rarely ,after reset if i reload the image and run
> it goes to sys_halt state. After comparing text area in L2 for success case and failure
> case , i found some text area is different . Those memory locations are from rts library .
> Also used hardware breakpoint to monitor if some code is writing into code area , but
> nothing happened .Can anyone help me , what could be wrong here.
>
> Thanks
> Jai
------- End of Original Message -------

Jai-

> Even initially i had the same doubt , but verified the text area before
> execution . Its the same with OK case text area. After execution memory is
> getting changed .

Is the same area changed? If so then try placing a breakpoint on the first location of that area being modified, then
when the breakpoint occurs take a look at execution history and see the code was before it jumped the tracks.

-Jeff

> On 6/21/07, Jeff Brower wrote:
>>
>> Jai-
>>
>> > I have a strange problem . I am running an application on 6482 with
>> .text
>> > in L2 Memory. Its runs successfully 98% times . Very rarely ,after reset
>> if
>> > i reload the image and run it goes to sys_halt state.
>> > After comparing text area in L2 for success case and failure case , i
>> found
>> > some text area is different . Those memory locations are from rts
>> library .
>> > Also used hardware breakpoint to monitor if some code is writing into
>> code
>> > area , but nothing happened .Can anyone help me , what could be wrong
>> here.
>>
>> Did you compare the text (code) areas immediately after downloading,
>> before any code
>> runs? Maybe the download (I assume you are using JTAG) is not reliable.
>>
>> -Jeff
>

Jai,

--- Jeff Brower wrote:

> Jai-
>
> > I have a strange problem . I am running an
> application on 6482 with .text
> > in L2 Memory. Its runs successfully 98% times .
> Very rarely ,after reset if
> > i reload the image and run it goes to sys_halt
> state.
> > After comparing text area in L2 for success case
> and failure case , i found
> > some text area is different . Those memory
> locations are from rts library .

1. If you change the link order, does the problem
'follow' the rts library??

2. Are you using rts lib functions as re-entrant
code??
Some support reentrancy and some do not.

3. Does your hardware enable and use SRIO??

> > Also used hardware breakpoint to monitor if some
> code is writing into code
> > area , but nothing happened .Can anyone help me ,
> what could be wrong here.
>
> Did you compare the text (code) areas immediately
> after downloading, before any code
> runs? Maybe the download (I assume you are using
> JTAG) is not reliable.
>
> -Jeff
>

Jeff ,
Even initially i had the same doubt , but verified the text area before
execution . Its the same with OK case text area. After execution memory is
getting changed .

Jai

On 6/21/07, Jeff Brower wrote:
>
> Jai-
>
> > I have a strange problem . I am running an application on 6482 with
> .text
> > in L2 Memory. Its runs successfully 98% times . Very rarely ,after reset
> if
> > i reload the image and run it goes to sys_halt state.
> > After comparing text area in L2 for success case and failure case , i
> found
> > some text area is different . Those memory locations are from rts
> library .
> > Also used hardware breakpoint to monitor if some code is writing into
> code
> > area , but nothing happened .Can anyone help me , what could be wrong
> here.
>
> Did you compare the text (code) areas immediately after downloading,
> before any code
> runs? Maybe the download (I assume you are using JTAG) is not reliable.
>
> -Jeff
>

Jai-

> I have a strange problem . I am running an application on 6482 with .text
> in L2 Memory. Its runs successfully 98% times . Very rarely ,after reset if
> i reload the image and run it goes to sys_halt state.
> After comparing text area in L2 for success case and failure case , i found
> some text area is different . Those memory locations are from rts library .
> Also used hardware breakpoint to monitor if some code is writing into code
> area , but nothing happened .Can anyone help me , what could be wrong here.

Did you compare the text (code) areas immediately after downloading, before any code
runs? Maybe the download (I assume you are using JTAG) is not reliable.

-Jeff

Hi ,
I have a strange problem . I am running an application on 6482 with .text in L2 Memory. Its runs successfully 98% times . Very rarely ,after reset if i reload the image and run it goes to sys_halt state.
After comparing text area in L2 for success case and failure case , i found some text area is different . Those memory locations are from rts library .
Also used hardware breakpoint to monitor if some code is writing into code area , but nothing happened .Can anyone help me , what could be wrong here.

Thanks
Jai