VDD PLL connection on MCF5208CVM166, LBGA196

[Jack_]

I am modifying a board with the Cooldfire MCF5208, changing from the QFP to the BGA package. With the QFP version we never had any problems but now, with the BGA version we have a lot of problems with program crashes.

We suspect that the problem may come from the internal PLL since if we disable it the problems disappear.

Looking at the schematics of two versions of the evaluation boards  M5208EVB that use the BGA version of the chip, they indicate a different connection of the J12 pin. In revision B board, J12(VDD_D_PLL) is connected to H13 (VDD_A_PLL) whereas in revision E evaluation board J12 is connected to IVDD.

We have taken revision E as a reference for the design and we have connected J12 to IVDD, but we have many problems with the board hanging.The program hangs and seems to happen more when we raise the temperature of the board. If we override the PLL, the board works without problems.

We also tested the board by putting a 40MHz oscillator in place of the 16MHz crystal (with the PLL disabled of course) and the board worked fine even at high temperatures (75°C)

 We are thinking of making a new PCB connecting J12 to H13 instead of IVDD.

Has anyone had a similar problem?

 What is the correct connection?

Thanks,

Joan

[Jack_]

I want to add some information about the PCB that is giving us problems:

4 Layers PCB

BGA pads: 0.45mm

Vias drill in BGA area: 0.25mm

Vias diameter in BGA area: 0.55mm

Wire width to BGA pads: 0.15mm

Vias drill outside the BGA area: 0.4mm

Vias diameter outside the BGA area: 0.7mm

Wire width to data and address lines for flash and external RAM: 8 mils.

Jack

[TomE]

According to the Reference Manual, J12 on the MAPBGA196 is IVDD and not a PLL supply.

PLL_VDD is H13, and must be supplied with 1.5V.

IVDD connects to 6 different pins and must also be supplies with 1.5V.

EVDD connects to 14 pins and must be supplied with 3.3V.

SVDD connects to 13 pins and can take different voltages, depending on the memory technology.

There's also PLL_VSS. Is that connected properly? Is PLL_TEST NC? Is TEST grounded?

The reason for the PLL_VDD and PLL_VSS pins is that they have to be supplied with the same voltage as IVDD, but can be separately routed (from the supply chip) and have filtering to try and remove switching and other noise on that rail from disturbing the PLL.

Monitor FB_CLK and see if you can see any instability on that signal.

Using the Dev Boards as a reference is a good idea, but remember that the schematics might have mistakes and may not match the board exactly. Check all of your VDD and VSS connections against the Reference Manual and Data Sheet.

Do you have enough bypass caps on all of the rails, and close to the CPU.

Tom

[Jack_]

We have all the connections as you indicate, including PLL_TEST NC and TEST to ground.

We have 24 capacitors of 100nF (0402) and 2 capacitors of 10µF ceramics distributed by the different power supplies. The placement of these capacitors is as close as possible to the micro's power supply and most are under the micro itself on the underside of the pcb.

In the schematic of the evaluation board Revision B1, as I said, there is the signal J12 connected to H13. In the gerber files the connection also appears. It may be that the evaluation board we have does not correspond to this gerbers because I see some different via, even though, all the components are located at the same place.

It is also curious that on the evaluation board the decoupling capacitors are much further away from the pins since they are all mounted on the top side but instead the board works perfectly at any temperature.

Maybe one option would be to try to copy as much as possible the layout of the evaluation board so I also wanted to confirm the connection of J12.

[TomE]

That's a 166MHz part. What frequency are you running it at?

Disabling the PLL would make everything run a lot slower. You said you ran it with a 40MHz external clock. Is that the same speed you're running at with the PLL? That seems very slow.

If your tests without the PLL are running at a lower speed (and running OK), then I'd suspect your memory timing and signal integrity. All the bus timing would be slower and have wider margins at lower clock speeds.

You should be able to "margin test" your system by running at different PLL-generated clock rates above and below your design speed. It should work at higher speeds (and normal temperatures). You can actually "map out" the margins for temperature and frequency with enough work.

I had a situation with an i.MX chip with external DDR3 that had problems. NXP provide a Memory Test that can be run at different DDR clock speeds. That showed that the boards that failed had low frequency margins at high and low temperatures. That turned out to be related to variations in the board layer thicknesses. Changing the programmable DDR drive strength by "one notch" fixed the problem.

Are you running SDR or DDR? Is it running code from Flash or from external RAM? Have you tried it with and without the Cache? Cache burst line fills can show problems that non-cached fetches don't.

Can you trap the crashes? Can you get it to fail under a debugger and add breakpoints to illegal instruction traps?

Tom

[Jack_]

We work at 88MHz. Yes, indeed 40 MHz is a bit slow, but I did the test to override the PLL and check the behavior of the board.

One of the tests I have done has been to remove the 100nF capacitor from the PLL power decoupling (after the filter) leaving only a 10µF ceramic capacitor and the two boards with BGA package tested do not boot with PLL. If I do the same test on the old board with the QFP package the board works OK. I know it is not correct to remove this capacitor, but it was to see the sensitivity of this part of the circuit on the two versions of the design.

The program runs from flash and we have static RAM using chipselect 1.

I have tried to modify the timings through the CSCR0 and CSCR1 registers to give more time to the bus by adding wait states and increasing the setup times, but it has not brought any improvement.

I have made a very short program that runs entirely inside the cache of the micro so that it does not access either the flash or the RAM. After starting the program I went up to 75 degrees and the board ran smoothly at 88MHz (PLL on). Then I repeated the test by accessing the flash but only doing data reading tests regardless of whether the read value was correct or not. The code was still in the micro's cache and accessing the flash to read its contents caused the board to hang.

I also tried with the normal program to disable the cache memory but I still have the same problems.

I did a test running with emulator and most of the times when the board hung, the connection with the micro was lost and we cannot know where the code is running. Sometimes the mcf5xxx_exception_handler() interrupt came in and would stop at the following options:

case 11: printf(EXCEPTFMT, "Unimplemented F-Line Instruction", \ MCF5XXX_SF_PC(framep));

case 4: printf(EXCEPTFMT, "Illegal instruction", MCF5XXX_SF_PC(framep));

With the PLL configuration we can only raise the working frequency and cannot lower it.

That's why we tried with an oscillator at 40MHz (maximum allowed speed) and disabling the PLL.

Jack

[TomE]

Those are good tests.

Reading the Flash is driving the address bus. Then the Flash chip drives the data bus. Both of those draw current from the 3V3 rail and ground. Some part of that cycle looks to be generating noise that is getting into the PLL's power supply and making it fail.

You should be able to run code from the internal SRAM reliably too.

Monitor MISCCR[PLLLOCK] and see if you can see it unlocking.

I would suggest programming a spare chip select to a range of memory that selects nothing (no peripherals). Then read from all-zeros address in that block. Then read from all-ones addresses. Then alternate all-zeros and all ones (the worst case). See if any of those patterns of address bus activity stop it from working (or have PLLLOCK go off). Then try writing all-ones and all-zeros to those addresses to involve the data bus drivers. Are you running a 16 or 32 bit data bus? 32 data plus 24 address lines is a lot of switching current.

Ramp the temperature up during those tests to measure "how stable is it during each test".

A good test would be to run the chip from the external clock with the PLL running, but not providing the clock to the CPU. Then you could monitor PLLLOCK. A lot of chips work this way (you switch to a fixed clock to reprogram the PLL), but it doesn't look like this one (or the MCF5235 we use) can work that way.

Do you have multiple boards behaving the same way, or only the one prototype? It might have a hardware fault like a bad solder joint under the chip.

Only four layers? Do you have ground and 3V3 layers? I'm thinking you might have ground and three track layers as you have to "escape" four rows of pads around the VSS/VCC block in the middle. Then there's IVDD and PLL_VDD to route.

Having it fail badly without the 100nF caps is certainly a symptom. Can you measure noise on PLL_VDD with and without that cap? 100nF is pretty large and maybe inductive. Try adding some 10nF caps as well (soldered across the 100nF) and see if that helps.

> With the PLL configuration we can only raise the working frequency and cannot lower it.

You could possibly run with a slower crystal (12MHz or 8MHz) to lower the PLL speed. I don't think that test would tell you anything though. You know the PLL is unstable and crashing the CPU.

Tom

[Jack_]

Thanks for your suggestions @TomE .

I will try to do some of these tests that you suggest but it could be that when the CPU is running at low clock it does not generate enough noise to make the PLL lose. I am almost sure that the problem appears when there is a lot of movement of the bus lines (address and data) at 88MHz clock.

I would like to ask you a question about the decoupling capacitors: do you think that using  0402 size instead of 0603 might make the behavior worse? In the old board design, I used 0603 combining 100nF,1nF and 220pF and it worked fine. In the new one I unified to 100nF [0402]. I've tried adding smaller capacitors in parallel but haven't seen any improvement.

I've also tried removing the 220pF capacitors from the old design and it still works fine.

I tried lowering the crystal to 12MHz but the board doesn't work. It seems that this micro MCF5208 can only work with PLL with a 16MHz crystal. I tried the old board with QFP package with a 12MHz crystal and it works for a while then it hangs. I think it is a limitation of the MCF5208.

I do not use a power layer (3V3) because in a first version of the board that we had a layer with 3V3, the board did not work at all with PLL. Now I have ground planes on all layers (I can't dedicate a layer exclusively to ground) and I get the signals from the path as tidy as possible trying to avoid crosstalk between layers. 

I add some information about the PCB that is giving problems:

 4 Layers PCB

BGA pads: 0.45mm

Wire width to BGA pads: 0.15mm

Vias drill in BGA area: 0.25mm

Vias diameter in BGA area: 0.55mm

Vias drill outside the BGA area: 0.4mm

Vias diameter outside the BGA area: 0.7mm

Wire width to data and address lines for flash and external RAM: 8 mils.

Jack

[TomE]

Here's another thing to look at. It might be a problem with the Crystal. You may be getting noise on that. It might be glitching or stopping and that might be tripping the PLL. Have you tried a 16MHz hybrid crystal oscillator to eliminate that possibility? Have you run a "gain margin test" on your crystal? Have you tried changing the capacitors on the crystal just to see if there's a difference?

I'd suggest running those tests with different data and address patterns to "nothing" and to Flash or RAM. I've had that on a board which ran fine as long as you didn't give it a "worse case" (all ones to all zeros) data and address pattern. You might be able to find WHICH data or address bus lines it is most sensitive to. That might show up what's wrong with the layout or something.

Listing the track and via sizes doesn't tell me anything. That you don't have a Ground Plane is a lot more worrying. I assume you have different ground polygons on different layers, and then tie them together with vias. There are so many ways that can go wrong.The point of a ground plane is to guarantee every signal is a "Stripline" over ground with constant impedance and with the smallest possible current loops. If a signal is going over ground polygons on different layers that are only linked 10mm away from the track then the transmission line current has to flow out through that via, and that forms a big loop. So you need a via between polygons at every point a signal track goes over the junction between the polygons.

There should be continuous ground from all (24 address lines and 32 data and control) lines to the RAM and Flash (and any other devices). The grounds need to be continuous from the CPU pins to the Flash and SRAM pins. You also want continuous grounds under all paths from the power supplies to the power supply pins on all chips. And all bypass capacitors. Your board with the 3V3 plane might have been able to provide this function using the 3V3 plane (coupled back to ground via bypasses). It may have failed for other reasons.

I think your problem is mainly with the 1.8V supply to the PLL pin. Or maybe the PLL Ground pin. That's getting noise on it somehow. Have you looked with a good oscilloscope to see if you can see noise? You might be able to see a difference between "running in cache and not crashing" versus "accessing the external bus and crashing" cases.

I would also suspect your 3V3 or 1V8 power supplies. Maybe they're unstable. Can you feed power in from external (bench) supplies to see if it changes anything?

Bypass capacitors are very much "black magic", but they usually assume they're connecting to a ground plane. Other wise they could couple VCC noise into a badly connected ground polygon. Search for "decoupling multiple values" for lots of interesting opinions:

https://electronics.stackexchange.com/questions/400683/do-chips-really-need-multiple-values-of-decou...

Read NXP AN1282, AN2742 and AN1741. Search for other ones. Google for "AN11400".

Renesas AN1325 is worth a read.

Tom

[Jack_]

Hi Tom,

I wanted to tell you that I finally solved the problem with a new layout.

I moved the decoupling capacitor closer to the PLL power supply and also removed all the vias  to ensure, as much as possible, that no interference from this point enters the PLL.

I have also changed the distribution of the power supplies a bit (3V3 and 1V5) so that the effect of the decoupling capacitors is more effective from the microcontroller's point of view.

I have also changed the crystal for an oscillator although this test had already been done with the old layout without improvement.

Although I do not have a continuous ground plan, I have ensured that the continuity is as high as possible by placing vias in several places.

Now the board works fine, I've put it up to 75 degrees Celsius and it hasn't failed.

Thanks for the support and ideas provided.

Best regards,

Jack

[TomE]

> I wanted to tell you that I finally solved the problem with a new layout.

That's good, but I was surprised/worried by the following:

> Although I do not have a continuous ground plan

I think that's your problem. Pretty much nobody (outside the $0.50 Alibaba toy market) doesn't use a continuous ground plane. The ground plane does more than provide a low noise reference plane. It also (for free) turns every signal path into a stripline. That's the circuit board equivalent of a twisted pair. The current flowing in every track is matched by a "return current" flowing in the ground plane directly under that track. That happens automatically to minimize the energy (of the magnetic field), and that minimizes emissions and coupling between different tracks.

If you don't have a continuous ground plane under all the Address, Data and control tracks between the Flash, RAM and CPU, when what you have are a lot of large circular aerials, broadcasting noise to the outside world, and into every other "aerial" on the board. Check your layout and see where the "return current loops" are. They have to divert from whatever ground plane is under a track to the nearest via that couples it back beyond the "break" in whatever "planes" you have. Maybe you don't have planes at all, but just "ground traces wandering around the board" that you're trying to grid together?

I'm pretty sure that all of the Reference Boards have Ground Planes as well (usually) as VCC Planes.

Tom