Stability of DSP according to the production time

Hi all,

I'm struggling to resolve the strange problem with c54x. My code
works well on some DSP chips, but does not on the other DSPs. The
only difference between them is DSP LOT number on the chips as I
know on.

Because I have developed the code with some good(for me, :-) ) DSP
chips, I cannot know such problem before. Although some hardware
engineers and I have investigated this, we cannot suspect some
faults of hardware. It seems that its working depends on only DSP
for now.

To be more strange, I could make my code work well even on the bad
DSP with some modifications. (The modifications are so trivial, I
think they should not make any effects on the stability of DSP
working.)

I'm still curious why my code works well on some DSPs and does not
on the other DSPs.

Have you ever faced similar problem with c54x?

Best Regards,
Kay-T Start a New Thread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kt_rhee wrote:
> Hi all,
>
> I'm struggling to resolve the strange problem with c54x. My code
> works well on some DSP chips, but does not on the other DSPs. The
> only difference between them is DSP LOT number on the chips as I
> know on.
>
> Because I have developed the code with some good(for me, :-) ) DSP
> chips, I cannot know such problem before. Although some hardware
> engineers and I have investigated this, we cannot suspect some
> faults of hardware. It seems that its working depends on only DSP
> for now.
>
> To be more strange, I could make my code work well even on the bad
> DSP with some modifications. (The modifications are so trivial, I
> think they should not make any effects on the stability of DSP
> working.)
>
> I'm still curious why my code works well on some DSPs and does not
> on the other DSPs.
>
> Have you ever faced similar problem with c54x?
>
> Best Regards,
> Kay-T
>

First check the errata pages for your DSP. TI lists the errors and which
production runs they apply to.

Can you build a simple test case? If so send it to TI and they will have
an engineer look into it.

Are you sure the difference is the DSP? Have you tried making the same
changes to the code running on a 'good' dsp?

This sounds to me like a stack, pointer error or memory initialization
problem. Different lots may have a tendency to boot with different
memory values that may make it look like a hardware problem when it is
really software.

Brian

- --
- ---[Office 71.4F]--[Outside 51.6F]--[Server 84.3F]--[Coaster 71.6F]---
Software, Linux, Microcontrollers http://www.brianlane.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Remember Lexington Green!

iD8DBQFE8Z4+Iftj/pcSws0RAgj0AJ4m6TowEeP2kjyTKd1fsUjLw4HoYgCdEcbI
ZGT8q+ju+DM5JNCIdtI3o84=vTtR
-----END PGP SIGNATURE----- Start a New Thread

KT Rhee-

> I'm struggling to resolve the strange problem with c54x. My code
> works well on some DSP chips, but does not on the other DSPs. The
> only difference between them is DSP LOT number on the chips as I
> know on.
>
> Because I have developed the code with some good(for me, :-) ) DSP
> chips, I cannot know such problem before. Although some hardware
> engineers and I have investigated this, we cannot suspect some
> faults of hardware. It seems that its working depends on only DSP
> for now.
>
> To be more strange, I could make my code work well even on the bad
> DSP with some modifications. (The modifications are so trivial, I
> think they should not make any effects on the stability of DSP
> working.)

You can make modifications that fix the problem? In that case:

1) Post an example of a mod.

2) Why not make the modifications for all units and be done?

Also, how sure are you the modifications fix the problem? Do you have an
automatic test to boot the board 1000s of times and run the code for weeks
to verify it is reliable? This sort of testing is required to create a
dependable product.

> I'm still curious why my code works well on some DSPs and does not
> on the other DSPs.
>
> Have you ever faced similar problem with c54x?

I've seen this sort of thing before on various devices: DSPs, FPGAs,
microprocessors. When the difference was silicon (revision) then it was
typically a chip/hardware problem, for example pull-up/pull-down R, heat
condition, timing on some signal, shape of Reset pulse, clock noise, etc.
When the difference was Mfg Lot number only, the problem was always
software. As Brian mentioned, you could easily have a stack or memory
initialization issue.

-Jeff Start a New Thread

KT Rhee-

> --- In c..., "Jeff Brower" wrote:
> >
> > KT Rhee-
> >
> > > I'm struggling to resolve the strange problem with c54x. My code
> > > works well on some DSP chips, but does not on the other DSPs. The
> > > only difference between them is DSP LOT number on the chips as I
> > > know on.
> > >
> > > Because I have developed the code with some good(for me, :-) )
> DSP
> > > chips, I cannot know such problem before. Although some hardware
> > > engineers and I have investigated this, we cannot suspect some
> > > faults of hardware. It seems that its working depends on only DSP
> > > for now.
> > >
> > > To be more strange, I could make my code work well even on the
> bad
> > > DSP with some modifications. (The modifications are so trivial, I
> > > think they should not make any effects on the stability of DSP
> > > working.)
> >
> > You can make modifications that fix the problem? In that case:
> >
> > 1) Post an example of a mod.
> >
> > 2) Why not make the modifications for all units and be done?
> >
> > Also, how sure are you the modifications fix the problem? Do you
> have an
> > automatic test to boot the board 1000s of times and run the code
> for weeks
> > to verify it is reliable? This sort of testing is required to
> create a
> > dependable product.
> >
> > > I'm still curious why my code works well on some DSPs and does
> not
> > > on the other DSPs.
> > >
> > > Have you ever faced similar problem with c54x?
> >
> > I've seen this sort of thing before on various devices: DSPs,
> FPGAs,
> > microprocessors. When the difference was silicon (revision) then
> it was
> > typically a chip/hardware problem, for example pull-up/pull-down
> R, heat
> > condition, timing on some signal, shape of Reset pulse, clock
> noise, etc.
> > When the difference was Mfg Lot number only, the problem was always
> > software. As Brian mentioned, you could easily have a stack or
> memory
> > initialization issue.
> >
> > -Jeff
> > The modifications are not the specific codes. The working depends on
> the some variable adding and deletion, and memory map changes. So, I
> think it's of no use to post an example of a mod.(Maybe, they would
> be related with memory allocation.)
>
> Anyway, I found something new I have looked over. I'm using a C5401
> with only internal SRAM. By the memory map of C5401 manual, there
> are the reserved area between address 0x3000~0x3ffff. What I'm
> suspecting is that I am using this area. (I'm afraid that I have
> done so stupid things.. ) Do you think this may make any effect at
> booting?
>
> So far, I had used this area in many system with C5401, so I didn't
> think about it.

Yes I think that could make a difference. That's a big piece of reserved memory,
anything could be in there -- maybe some registers for TI use only. I would try some
experiments and make sure via .map file you are not using the reserved area, and see
what happens.

-Jeff Start a New Thread

KT Rhee-

> --- In c..., "Jeff Brower" wrote:
> >
> > KT Rhee-
> >
> > > I'm struggling to resolve the strange problem with c54x. My code
> > > works well on some DSP chips, but does not on the other DSPs. The
> > > only difference between them is DSP LOT number on the chips as I
> > > know on.
> > >
> > > Because I have developed the code with some good(for me, :-) )
> DSP
> > > chips, I cannot know such problem before. Although some hardware
> > > engineers and I have investigated this, we cannot suspect some
> > > faults of hardware. It seems that its working depends on only DSP
> > > for now.
> > >
> > > To be more strange, I could make my code work well even on the
> bad
> > > DSP with some modifications. (The modifications are so trivial, I
> > > think they should not make any effects on the stability of DSP
> > > working.)
> >
> > You can make modifications that fix the problem? In that case:
> >
> > 1) Post an example of a mod.
> >
> > 2) Why not make the modifications for all units and be done?
> >
> > Also, how sure are you the modifications fix the problem? Do you
> have an
> > automatic test to boot the board 1000s of times and run the code
> for weeks
> > to verify it is reliable? This sort of testing is required to
> create a
> > dependable product.
> >
> > > I'm still curious why my code works well on some DSPs and does
> not
> > > on the other DSPs.
> > >
> > > Have you ever faced similar problem with c54x?
> >
> > I've seen this sort of thing before on various devices: DSPs,
> FPGAs,
> > microprocessors. When the difference was silicon (revision) then
> it was
> > typically a chip/hardware problem, for example pull-up/pull-down
> R, heat
> > condition, timing on some signal, shape of Reset pulse, clock
> noise, etc.
> > When the difference was Mfg Lot number only, the problem was always
> > software. As Brian mentioned, you could easily have a stack or
> memory
> > initialization issue.
> >
> > -Jeff
> > The modifications are not the specific codes. The working depends on
> the some variable adding and deletion, and memory map changes. So, I
> think it's of no use to post an example of a mod.(Maybe, they would
> be related with memory allocation.)
>
> Anyway, I found something new I have looked over. I'm using a C5401
> with only internal SRAM. By the memory map of C5401 manual, there
> are the reserved area between address 0x3000~0x3ffff. What I'm
> suspecting is that I am using this area. (I'm afraid that I have
> done so stupid things.. ) Do you think this may make any effect at
> booting?
>
> So far, I had used this area in many system with C5401, so I didn't
> think about it.

Yes I think that could make a difference. That's a big piece of reserved memory,
anything could be in there -- maybe some registers for TI use only. I would try some
experiments and make sure via .map file you are not using the reserved area, and see
what happens.

-Jeff Start a New Thread

KT-

> Hi Jeff, Brian and news members
>
> The culprit was my stupid mistake. To initialize some variables was
> overwritting my running DSP code according to the trash value of
> memory. I misunderstood that it depended on DSP revision. :-$
>
> I should have checked my code once more before suspecting hardware,
> DSP revision and so on. Sorry for my carelessness.
>
> Thanks for your helps and advices.

Haha, there is no dumb bug once you figure it out -- only a dead bug :-)

But the group was sort of persistent in urging you to check for software issues
again, huh. I bet group members have a lot of experience with their own such bugs
like this :-)

Thanks for letting everyone know.

-Jeff

> --- In c..., Jeff Brower wrote:
> >
> > KT Rhee-
> >
> > > --- In c..., "Jeff Brower" wrote:
> > > >
> > > > KT Rhee-
> > > >
> > > > > I'm struggling to resolve the strange problem with c54x. My
> code
> > > > > works well on some DSP chips, but does not on the other
> DSPs. The
> > > > > only difference between them is DSP LOT number on the chips
> as I
> > > > > know on.
> > > > >
> > > > > Because I have developed the code with some good(for me, :-
> ) )
> > > DSP
> > > > > chips, I cannot know such problem before. Although some
> hardware
> > > > > engineers and I have investigated this, we cannot suspect
> some
> > > > > faults of hardware. It seems that its working depends on
> only DSP
> > > > > for now.
> > > > >
> > > > > To be more strange, I could make my code work well even on
> the
> > > bad
> > > > > DSP with some modifications. (The modifications are so
> trivial, I
> > > > > think they should not make any effects on the stability of
> DSP
> > > > > working.)
> > > >
> > > > You can make modifications that fix the problem? In that case:
> > > >
> > > > 1) Post an example of a mod.
> > > >
> > > > 2) Why not make the modifications for all units and be done?
> > > >
> > > > Also, how sure are you the modifications fix the problem? Do
> you
> > > have an
> > > > automatic test to boot the board 1000s of times and run the
> code
> > > for weeks
> > > > to verify it is reliable? This sort of testing is required to
> > > create a
> > > > dependable product.
> > > >
> > > > > I'm still curious why my code works well on some DSPs and
> does
> > > not
> > > > > on the other DSPs.
> > > > >
> > > > > Have you ever faced similar problem with c54x?
> > > >
> > > > I've seen this sort of thing before on various devices: DSPs,
> > > FPGAs,
> > > > microprocessors. When the difference was silicon (revision)
> then
> > > it was
> > > > typically a chip/hardware problem, for example pull-up/pull-
> down
> > > R, heat
> > > > condition, timing on some signal, shape of Reset pulse, clock
> > > noise, etc.
> > > > When the difference was Mfg Lot number only, the problem was
> always
> > > > software. As Brian mentioned, you could easily have a stack or
> > > memory
> > > > initialization issue.
> > > >
> > > > -Jeff
> > > >
> > >
> > > The modifications are not the specific codes. The working
> depends on
> > > the some variable adding and deletion, and memory map changes.
> So, I
> > > think it's of no use to post an example of a mod.(Maybe, they
> would
> > > be related with memory allocation.)
> > >
> > > Anyway, I found something new I have looked over. I'm using a
> C5401
> > > with only internal SRAM. By the memory map of C5401 manual, there
> > > are the reserved area between address 0x3000~0x3ffff. What I'm
> > > suspecting is that I am using this area. (I'm afraid that I have
> > > done so stupid things.. ) Do you think this may make any effect
> at
> > > booting?
> > >
> > > So far, I had used this area in many system with C5401, so I
> didn't
> > > think about it.
> >
> > Yes I think that could make a difference. That's a big piece of
> reserved memory,
> > anything could be in there -- maybe some registers for TI use
> only. I would try some
> > experiments and make sure via .map file you are not using the
> reserved area, and see
> > what happens.
> >
> > -Jeff
> > Start a New Thread