Thanks for the feedback. We do have the 200ms delay in our startup|
code, we modified the SDK file "plldrv.c" to get a 240ms delay. Even
after this change, we had oscillator startup failures at anything below
0C (32F), on several DSP56F807 Rev. D chips. I verified that it was the
oscillator itself and not the PLL or some other part of the chip. What
I did was that I connected a high-impedance, low-capacitance probe and
looked at the oscillator output directly (ie before it goes through any
other internal circuits). It was definitely the oscillator itself that
was failing, not the PLL or some other part of the chip. Going to the
external oscillator and schmitt trigger chip fixed the problem.
Art Johnson -----Original Message-----
From: mwmann_at_motorola [mailto:]
Sent: Thursday, September 05, 2002 2:21 PM
To: Art Johnson
Subject: Re: 56F807 expected life cycle --- In motoroladsp@y..., "Art Johnson" <art@p...> wrote:
> We are designing the DSP56F807 into many of our new products. This
> family of devices are in the "ramp-up" stage at Motorola and so
> be available for many years to come. I can't say what kind of
> share these devices have, but I do know there are many companies
> these chips in their new products. On prices, nobody but Motorola
> say for sure, but historically all new products have a downward
> prices as production ramps up and device yields improve with process
> A few comments based on over 16 month's experience with the
> 1) Use an external WatchDog Timer (WDT) chip, we use the
> MAX6320PUK29CY-T (PDF file is attached). Note that both /RESET and
> /TRST must be asserted for a proper power-on reset. /RESET is
> either directly from the WDT chip or indirectly using an AND gate.
> /TRST can be either tied to ground through a 1.0 kohm resistor, or
> can also get the WDT reset signal through another AND gate.
You can simply ground /TRST as long as you don't intend to use the
JTAG port. /TRST must be driven by the JTAG port for debugging,
hence the need for a pull down resistor instead of a dead short.
> 2) The internal crystal oscillator does not start up reliably at low
> temperatures even on the latest (Rev. D) chips, despite what
> may say. We spent many weeks trying different circuits and
> values to get it to work, without success. The only thing that does
> work reliably is an external oscillator (Raltron CO63310-7.3728-EXT-
> going through a "speed-up" schmitt trigger (ON Semi NL17SZ14) to the
> XTAL pin, and the EXTAL pin is grounded (PDF files are attached).
Included in the current errata:
12.3 PLL Stabilization Time
Maximum PLL stabilization time is 200ms under worst case (-40)
conditions. Typical PLL stabilization time remains at 10ms (25
Insert a 200ms delay after power up to allow the PLL to settle or
verify the Loss of Lock bits (LCK0 and LCK1) in the PLL Status
Register (PLLSR) are set to 1 prior to program execution.
-- So you will have to modify your startup code to wait for these
lock bits to set.
> 3) If you haven't already bought a Real Time Operating System
> would very strongly recommend the DSPOS operating system. It's very
> fast, uses a very small ROM/RAM footprint, and has rock-solid
> and reliability. The very few problems we did encounter were
> and fixed immediately, which was very nice to see. We've found that
> using an RTOS has saved us a great deal of time compared to trying
> develop our own scheduling algorithm. DSPOS is located at:
> 4) Get Metrowerks CodeWarrior version 5.0 and the 5.0.2 patch.
> versions of CodeWarrior had some very serious bugs that are fixed in
> version 5.0 + 5.0.2. There are still some minor bugs in 5.0.2, but
> there are simple workarounds for all of them.
> 5) We have developed an "informal network" of DSP56800 users to
> information on hardware/software bugs, as it seems to be the only
> readily find out this sort of information. Several times we
> hardware or software bugs, and when we asked the Technical Solutions
> Manager at our local Motorola distributor, we found out that other
> (or even Motorola) had experienced the same problems, but this
> information was not available on any FAQs or discussion groups.
DSP Standard Products Organization handles the hardware and SDK side
of the product line. Another part of Motorola, Metrowerks, is
responsible for CodeWarrior.
As part of the DSP Standard Products Operation, I can assure you that
we post FAQs on new problems and workarounds as soon as we find
them. Just this week we have added three additional FAQs.
> I hope this information is helpful to you, please feel free to
> me if you have any more questions or would like further information
> about the 56800 family.
> Art Johnson
> Senior Systems Analyst
> PMC Prime Mover Controls Inc.
> 3600 Gilmore Way
> Burnaby, B.C., Canada
> V5G 4R8
> Phone: 604 433-4644
> FAX: 604 433-5570
> Email: art@p...
> http://www.pmc-controls.com >
> -----Original Message-----
> From: dbo_exendis [mailto:22hlbojrr9001@s...]
> Sent: Thursday, September 05, 2002 5:58 AM
> To: motoroladsp@y...
> Subject: [motoroladsp] 56F807 expected life cycle > Dear Members,
> For evaluation purposes i would like to have (independent !)
> information of the expected availability of the 56F807 DSP in the
> We have plans to develop a controller system around this DSP.
> For us it is important to know:
> How long the DSP will be available at reasonable prices ?
> Does anyone have an idea what share of the DSP market is taken by
> this DSP family ?
> Can we expect a price drop in the near future ?
> Thanks in advance,
> Donald Bosch >
> Note: If you do a simple "reply" with your email client, only the
> of this message will receive your answer. You need to do a "reply
> if you want your answer to be distributed to the entire group.
> About this discussion group:
> To Join: motoroladsp-subscribe@y...
> To Post: motoroladsp@y...
> To Leave: motoroladsp-unsubscribe@y...
> Archives: http://www.yahoogroups.com/group/motoroladsp
> More Groups: http://www.dsprelated.com/groups.php3 > ">http://docs.yahoo.com/info/terms/