Re: The MCF52230 issue

David Brown <[email protected]>
Newsgroups gmane.comp.hardware.motorola.microcontrollers.coldfire
Organization WestControl a.s
Message-ID <[email protected]>
Peter Hallenbeck wrote:
>   Since one out of six boards works intermittently, as a 1st pass assumption
> let's rule out wiring error.  There may be assembly errors on the other
> five, but one out of six seems like a high assembly error rate.  I'm sure
> you have this covered, but verify that each power pin really connects to
> power.  Sometimes things work with a power pin left off as power is fed
> through the various protection diodes for the pins.
> 
>   The only thing I can see that is different between your schematic and the
> demo board is the bypass capacitors.  The PLL bypass as a .001 uF (1000 pF)
> on it.  The analog supply has a 10uF tantalum on it.
> 
>   In general, my bypass regiment tends to be board level bulk (low ESR
> 100uF), .1uF and .001uF.  The two chip caps cover a broad chunk of
> bandwidth.  I've even put 100pF caps on things like SDRAMS and one or two by
> the processor (on a 5282), particularly if it's not a multi layer PCB.
> Another advantage of the dual cap approach can be seen if you take a
> spectrum analyzer and put it on some of the wire coming off your board.  The
> emissions aren't as bad.
> 
>   And finally, because of the nature of surface mount bypass caps this is a
> very quick and easy thing to try to do.  You can put a .001 uF cap on top of
> your .1's and see what happens.  You may also look at the power supply noise
> with a scope and see if you can see any difference at the highest speeds.
> You can also look at the power supply noise with a spectrum analyzer and see
> if it's cleaner.
>   I know most people that do digital design don't have spectrum analyzers.
> I've got on because I do a lot of RF work too.  With EMI concerns, I'd claim
> it's a tool that pretty much a requirement anymore.  The win is that once
> you have one, you can look at power supply noise from two different "angles"
> using your scope and your spectrum analyzer.
> 
>   So take an hour and solder some .001 caps on your .1 caps.  If the one
> flaky board runs better, you're on the right track.  If there's no change
> you've only lost an hour.
>   I'm had some serial port problems on a HCS08 that I haven't found a cure
> for in two years!  So I'm changing all the HCS08s out to 52233s.   It will
> be the "little" micro in the toolbox so that all things big and small can be
> on the network. So when you find the problem let us know!
> 

My thoughts on bypassing are bit different.  Many people view bypassing 
as a sort of black magic, some feel they can "prove" that their method 
is the correct way, some religiously follow manufacturers guidelines, 
and others just throw some caps at the board and see what sticks.  This 
is my way - based on things I've read that sound scientifically 
reasonable, and on experience, but with absolutely no guarantees!

If you look at a capacitor's impedance-frequency graph, you get a sort 
of V.  At lower frequencies, it acts as a capacitor (lower impedance at 
higher frequencies).  At higher frequencies, it acts as an inductor 
(higher impedance at higher frequencies).  In the middle, there is a 
minimal impedance at its resonance frequency, where it acts as a 
resistor (at its ESR).  The inductance is almost entirely dependant on 
the package footprint, along with the layout on the board (wire lengths, 
via size and placement, etc.).  The ESR is mostly a matter of package 
*type* - larger capacitors in the same footprint will normally have more 
layers in parallel, and therefore lower ESR.  So if you compare two 
capacitors with the same footprint, the one with the higher capacitance 
is better in the "C" region, and is at least as good, often better, in 
the "L" region.  It's resonance frequency will be lower, but the smaller 
cap will be at best only slightly lower impedance at its higher 
resonance frequency.

The general rule, then, is to find the smallest footprint your 
production people are happy with (say, 0603), and then the largest 
capacitance easily and cheaply available in that package (I like 0603, 
100 nF).  Any time you think you need a 100 nF and a 10 nF in parallel, 
you simply use two 100 nF caps - they will do a better job.  By the time 
you get to the point in frequency when a smaller cap might be better, 
the difference is probably already lost in the impedance of the tracks 
and the chip's pins or balls.  Make sure you've got a couple of vias 
tight up against each pad of your 100nF cap and you've done as good a 
job as you can.

The only possible problem here is that with most of your caps of the 
same size (you need bulk caps as well, of course), you have a single 
resonant frequency.  If you are unlucky, you could get standing waves at 
that frequency flying across your power plane, or local maxima and 
minima in the voltage.  The answer here is to keep your power plane 
somewhat irregular - you don't actually need a power plane to be a solid 
plane (as long as fast signals are referenced to a good ground plane). 
Break your power plane into lumps, with a lump under each fast chip and 
its surround bypass caps, with thick tracks back to your power supply 
for low DC impedance.  Then there are no issues with standing waves, 
since they have no big plane to bounce around in.

> 
>   As a comment/question to the group:
> 
> 	I'm moving away from PCs (after a decade of windows, I've just had
> enough).  I've got a iMAC and am playing with it.  It will at least take
> over email and documents.  Is there a compiled version of gcc for the MAC
> out there?  I've also got to get a linux machine going to test software for
> the products I'm working on, and could just migrate everything to that
> machine.  If this is a better, easer approach, than I'd just get a bigger
> platform for linux.  I guess I'm hoping that the MACs unix underpinnings
> would make it equivalent to a linux box.  I like the idea of paying a bit
> more for the hardware, but it all comes from one source even though I find
> benign dictatorships distasteful.  I fully understand that this question is
> a mix of aesthetics, religion, and politics and that my mileage may vary.
> 

It should be possible to get gcc working on a MAC, but its more at home 
on Linux or "proper" BSD.  MACs are not much used for embedded 
development work, so you won't find much ready-made support.  For 
example, CodeSourcery have binaries and source tarballs for gcc for 
Linux (and windows), but if you want to use a MAC, you'll probably have 
to compile it yourself.  Similarly, you're more likely to get support 
for debugger tools under Linux than a MAC.

mvh.,

David


>  - pete
> 
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]]
>> On Behalf Of Sanjay Morab
>> Sent: Tuesday, February 05, 2008 7:41 AM
>> To: [email protected]
>> Subject: [ColdFire] The MCF52230 issue
>>
>> Dear Mark
>>
>> This is the extension the earlier problems of MCF52230. We had developed
>> the
>> all software on MCF52235 EVB and is working fine. We had made our board on
>> MCF52230 instead of MCF52235. The code is well with in limit. When we
>> tried
>> to download to SRM it gets down loaded but does not execute. Secondly we
>> had
>> tried to download to the flash, it it down loaded but does not execute. I
>> had cheked all votages ON VDD they are proper, The crystal frequency is
>> also25Mhz. Reset is OK. I do not know what is the matter.
>>
>> Out of 6 board made only one board is working that is also intermitantly.
>>
>> I am attaching the pdf of the schematic please go through the same and
>> tell
>> me is there any thing missing
>>
>> regards
>> Sanjay Morab
> 

---
[email protected]              Send a post to the list.
[email protected]        Join the list.
[email protected]    Join the list in digest mode.
[email protected]     Leave the list.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.