Dror-
> I need help with a problem I have with the
TMS320C6711B device.
>
> My design is in the production phase , and this issue has apeared
> a few months ago. Some of the cards were sent back from production
> with failures pointing at the TMS320C6711B circuits.
>
> What I saw using a scope on the CE1~ signal (connected to the code
> flash chip select) was "good" bootload sequences* lasting for
660
> usec and "bad" bootload sequences* lasting for only 21 usec.
>
> The "bad" bootload sequences always happen after a power cycle
and
> could not be recovered back by a reset pulse to the DSP device.
Can you temporarily set the failing cards to HPI boot mode, for example changing
a
pull-up/pull-down R? If so, then the first thing I would verify is that HPI
boot
mode is reliable, and there is not some other hardware thing going on. After
that,
some typical things that can bite include:
-unstable bootmode pull-up/down Rs, or R values that
are marginal (typically too weak)
-lack of pull-down on Reset line, and/or unstable
Reset line
-lack of pull-down on /TRST
-GPIO signals sharing pull-ups with other boot mode
(input only) signals
-unstable Vcc and PLL voltage levels, excessive
ripple, etc
-Vcc core and Vcc IO levels not ramping up in
acceptable sequence or duration
Since you say the issue appeared *after* you reached production phase, which
implies
you did not see it during development and prototype phase, then I would tend
to
suspect component values. Did you check to make sure all Rs and Cs are exactly
as
with the prototype boards? Assembly guys didn't slip a Mickey in on you did
they?
-Jeff
> Another non frequent (and strange) event that I
saw, was another 21 usec pulse or sometimes 10.5 usec pulse on the CE1~ signal
after a second or two, and sometimes even several of them.
>
> I have made some checks comparing the "bad" cards to the
"good" cards, and "bad" to "good" events on the
same card.
>
> - I have seen no difference in clock inputs/output behaviour
> - I have seen no difference in other output signals working during the boot
DMA (I have checked mainly address lines)
> - I have tried powering the DSP with different sequences (1.8V and 3.3V
order) with no effect.
>
> Can you please help me discover the possible cause for such a behaviour
(design, application, chip... )
>
> Thank you
>
> Dror Rapaport
> H/W eng.