EMI issue with bad power plane and SDRAM

[prasimix]

One could read many times how important it is if one wants to pass EMC and similar certifications to do in-house testing at all stages of testing. Unfortunately I haven’t been able to do that and now I’m looking at what can be done with what I have. I have already opened a couple of topics (link, link) on the topic of EM compatibility, and this is a new one.
On my last visit to an accredited lab, I passed a test for conducted emission for BB3. However, a new problem has arisen related to radiated emission. In fact it had been there from the beginning only that no measurements had been made before to indicate that.
There was a very pronounced interference on 108 MHz and the surrounding frequencies that I did not know at first where it came from.
I thought I would have to get a broadband antenna and make some test chamber to reproduce the problem, but it turned out to be very easy to catch if probed in the right place. In this case it was the RESET pin on the output connector of the MCU module! Probably this is no coincidence because RESET is tied with a pull-up to the +Vdd MCU.
If measured with an x10 probe on a 70 MHz oscilloscope it looks like this:



SA shows a pronounced 108 MHz but also several higher harmonics:



The first thing that came to my mind was that the problem was related to the dubious power supply of the MCU. For I no longer remember what reason I decided to power the MCU from a single point leading to a power plane (+Vdd) that is separate from the rest of the +3.3 V located on layer 3 of the PCB. It currently looks like this:



Yes, layer 3 is anything but optimal. Yesterday I immediately got to work and modified it to get as uniform as possible +3.3 V:



However yesterday I still didn’t know where those 108 MHz came from (the system clock is 216 MHz obtained by a prescaler from an external 25 MHz XTAL). Now I think this is related to SDRAM whose clock is set to twice smaller than the system, i.e. 108 MHz. When we lowered it to a third of the system clock, 72 MHz (and associated higher harmonics) appeared instead of 108 MHz.

This assumption is further confirmed by the test when we turned off SDRAM and switched the frame buffer to system RAM. Then the oscilloscope gives the following:



... or SA shows this:



The question is whether intervention on layer 3 is sufficient and what more could be done without switching from 4-layer to 6-layer PCB which I would like to avoid if at all possible. I see that ST's evaluation boards are made in 6 layers, I would like to believe that this is not a requirement for passing EMC tests.

Below is a picture of the point where I measure the massive ripple (RESET output):

[T3sl4co1l]

Layer 2 is solid?

That's still way more routing on layer 3 than I would approve.  And on layer 4, what traces are crossing those slots?  4 layers total, right?

Reset is generally a high impedance line, which implies some combination of three things:
1. The noise you measure is coupled in from a bypass cap, and the ground it returns to is dirty;
2. The noise is coupled from parallel traces, or crossing over particularly nasty ground slots;
3. The noise is common mode, and it appears when probing any net, including ground; the choice of RST was merely a coincidence, perhaps because it happens to be an inactive signal.

I recently routed a short SDRAM bus on a 2-layer board, which was probably a bit foolhardy, but it doesn't seem to be too noisy outside of the local area (as judged by a magnetic sniffer probe, and a bowtie antenna -- haven't done any conducted or radiated setups yet).  Key is the pinout from the host (an LCD controller), perfectly in order; the generous pitch (0.8mm) of the RAM chip doesn't hurt either, allowing me to route top and bottom traces with some ground pour around them.

Your situation is probably made less ideal by the MCU's higher pin density, longer routes, and possibly poorer pinout I'm not sure?  But that should be more than made up for by the ground planes.

Also, what all is on that big board-to-board header, besides RST?  And the LCD, is that driven by GPIOs or what?

Tim

[prasimix]

Layer 2 is solid?

Yes, more or less, please check all layers here.

That's still way more routing on layer 3 than I would approve.  And on layer 4, what traces are crossing those slots?  4 layers total, right?

Reset is generally a high impedance line, which implies some combination of three things:
1. The noise you measure is coupled in from a bypass cap, and the ground it returns to is dirty;
2. The noise is coupled from parallel traces, or crossing over particularly nasty ground slots;
3. The noise is common mode, and it appears when probing any net, including ground; the choice of RST was merely a coincidence, perhaps because it happens to be an inactive signal.

I made another measurement: move probe from RESET to GND (make short with probe GND cable). It doesn't look nice either:

Also, what all is on that big board-to-board header, besides RST?  And the LCD, is that driven by GPIOs or what?

Besides RST is backplane that carries up to three modules, but I made measurements with backplane removed, no improvement.

TFT is directly driven by MCU, I also tried to detach it completely and that also didn't help.

[T3sl4co1l]

Gah, just can't follow the traces.  Not enough visibility.

I'd have to look at the files, and preferably the physical build and what all was connected to it during the test.  And that'll take some hours to look at.

108MHz at least is on the low side, so if it's radiating, it's likely going up cables to do so.  We can already see something's going around (common mode) so that's very much possible, but I don't know how it was wired for testing.  The clock and harmonics are more likely to radiate from the board itself, though.

Is this important enough that you'd be interested in engaging professionally..?

Tim

[David Hess]

What kind of circuit is driving the reset signal?

There is a common reset circuit which involves an emitter follower which is prone to oscillation:

http://www.industrial-electronics.com/tac_9.html

[prasimix]

Gah, just can't follow the traces.  Not enough visibility.

I'd have to look at the files, and preferably the physical build and what all was connected to it during the test.  And that'll take some hours to look at.

108MHz at least is on the low side, so if it's radiating, it's likely going up cables to do so.  We can already see something's going around (common mode) so that's very much possible, but I don't know how it was wired for testing.  The clock and harmonics are more likely to radiate from the board itself, though.

Is this important enough that you'd be interested in engaging professionally..?

Tim

My first next step will be to redesign the PCB so that the SDRAM is as close to the MCU as possible (maybe I could put it on the bottom layer beneath the MCU!). If that doesn’t fix the situation I’ll start thinking about other options.

[prasimix]

What kind of circuit is driving the reset signal?

There is a common reset circuit which involves an emitter follower which is prone to oscillation:

http://www.industrial-electronics.com/tac_9.html

There is no reset circuit per se, only RC element. However the RESET line is all around the PCB and it is possible that due to its length and places it passes somewhere it picks up the clock frequency of the SDRAM.

[KE5FX]

Probing around on a board looking for EMI issues is usually a waste of time in my experience.  Nobody at the lab (or FCC) is going to be doing that.  If you don't already have a decent H-field probe, this would be a good time to buy or build one:



These can be used to good advantage with your scope as well as your spectrum analyzer. 

Another good video:

[prasimix]

I got Texbox EMC probe set with VNA, and already made some inspection, and will continue with that.

[jbb]

Hmm.
In the interest of not pulling your hair out, how about a quick bodge?
Connecting  C10 to nReset and Vcc is a little unorthodox; I would normally connect it to nReset and ground so that it pulls low at power up.
How about swinging C10 around to connect to ground instead?

Also, the STM32 might have a spread spectrum feature in the main PLL. Maybe that could spread out the energy over frequency and reduce the peak enough to squeak through?

[prasimix]

Yes, you're right, that capacitor doesn't belongs there. It remained as a "protection" from another phenomenon that I later found out what caused it (non-terminated debug cable that randomly knew how to reset the MCU). Anyway, if I removed it and probing the same place I got this:



Trying to move that capacitor from RESET to GND doesn't look good: it amplifies appearance of 108 MHz and its harmonics:

[T3sl4co1l]

It's just repeating the measurement we already know: there is a voltage drop from wherever RESET is anchored, to the pin.

Do you get a similar measurement from the bus lines?  (If there's no bus activity when the header is unplugged, just set them as active low.  If there is, override it to zero.)

Or active high. 

Purpose being, traces in a different environment (different neighbors) and supplied from a different IO bank, maybe there will be some insight about the MCU's power.

Also to clarify, you corrected the supply plane, but you're still testing the broken one..?

Also, in addition to moving traces off layer 3, I'd like to see via groups broken up: runs of vias cause large slots in both GND and VCC.  Nudging a few in the middle, just enough to get metal poured between, shrinks the opening by half.

Also also, I think I see a number of GND/VCC traces routed to the nearest via, which isn't always all that near?  Prioritize power pins and bypass caps, and if the connecting trace to any ground is more than say 100 mils, just drop a new via.  Vias are cheap.

Tim

[prasimix]

It's just repeating the measurement we already know: there is a voltage drop from wherever RESET is anchored, to the pin.

Do you get a similar measurement from the bus lines?  (If there's no bus activity when the header is unplugged, just set them as active low.  If there is, override it to zero.)

Or active high. 

Purpose being, traces in a different environment (different neighbors) and supplied from a different IO bank, maybe there will be some insight about the MCU's power.

In general, the situation looks similar on most of the pins of the 40-pin connector. SPI buses are live only if corresponding module is plugged in. The real difference makes disabling communication with SDRAM, possibly because it is not on the same potential as MCU (which has that isolated island od +Vdd connected with single point to the +3V3).

Also to clarify, you corrected the supply plane, but you're still testing the broken one..?

Yes, I still working with "broken" module, i.e. one that has isolated MCU Vdd power. Corrected L3 layout has to be manufactured if I decide to give it a try instead of complete redesign of SDRAM-MCU lanes with SDRAM on top or even moved to bottom layer.

Also, in addition to moving traces off layer 3, I'd like to see via groups broken up: runs of vias cause large slots in both GND and VCC.  Nudging a few in the middle, just enough to get metal poured between, shrinks the opening by half.

I'm not sure that I understand this one: what via groups?

Also also, I think I see a number of GND/VCC traces routed to the nearest via, which isn't always all that near?  Prioritize power pins and bypass caps, and if the connecting trace to any ground is more than say 100 mils, just drop a new via.  Vias are cheap.

When I started with layout, power pins were prioritized, i.e. decoupling 100n caps are placed near the MCU and SDRAM first. Caps GNDs are very close to pads.

[T3sl4co1l]

Stuff like highlighted --

Check layer 2, note the slots made by them.

BTW, the screenshots show tons of unconnected pads -- this is normal on the EDA side, and they're probably automatically removed in the Gerber output (or by the fab).  But it adds a lot of visual noise, especially when zoomed out, so it might be easy to miss, unless you're looking for it, or looking at the outputs.

Hmm, that's one thing Altium helps a bit with, pads and vias are drawn on the Multilayer layer, in gray (default colors).  Still a solid color, but less visual noise if you're looking for it.

Or if those are screenshots of the fab outputs -- enable "remove unconnected inner pads"!  It's a fab quality thing: extra copper puts more strain on the via plating.  Cheap fabs may remove it without asking (or leave it alone and not care..), full-service fabs will ask for confirmation.

Tim

[prasimix]

Ok, now I understand, but all that vias are functional, see how it looks when all 4 layers are visible:

[T3sl4co1l]

I didn't say delete, I said nudge.

[KE5FX]

Going to take a wild guess here and say that those particular vias are not a smoking gun.  I will say that I like to use more ground plane stitching vias than I'm seeing here.  I don't think I've ever generated a non-trivial board with less than two or three thousand vias total, most of which are plane stitching.

One concrete action item would be to provide via stitching around the periphery of the board.  Maybe one via per centimeter.  Otherwise, you have four large slot antennas.

What were you able to observe with the H-field probes?  Any leads there?

[T3sl4co1l]

Yeah, I'm guessing they aren't the problem either.  I listed that, among other things, as things that can be cleaned up.

I wonder if anything's resonating around 108MHz.  Could that plane under the MCU be doing it?  Or the plane around it, which is heavily cut up by the MCU plane and signal traces around it?

What if you swap out some bypass caps for lossy ones (R+C or tant)?

Also, can you highlight the VCC bypass caps and their connecting traces and vias?

Stitching is N/A on a 4 layer board without top and bottom pours, but I wonder if the next closest thing would be worth looking into: spread bypass caps around the board.  Remember, it doesn't much matter where caps are, with respect to pins; current is drawn from the plane, for the most part.  Local bypass is only meaningful when there isn't close access to the plane.  And use lots of vias (e.g. two vias per pad, flanking the body of the bypass cap) and short traces.

Rather hard to implement at this stage (on the physical board), but some evaluation can be made along that direction.  For example, find nearby GND/VCC pads in a given location, and attach coax very close to them.  Add ferrite beads to the coax.  Scope the supply ripple, AC coupling, 50 ohm terminated.  If a location doesn't have pads that are well enough isolated to test (i.e. don't use vias/pads on an active device), you can always dig down and expose planes directly -- it's destructive and a pain in the ass, but it can be done!  (Caps can be added in the same way, if you're really desperate.)

Tim

[jbb]

Tidying up the EMC design for the next release is well and good, but it’d be nice to tweak the existing board enough to pass.

Is there any opportunity to turn down the drive strength of the STM32 IO pins on the memory bus? That might squeeze out a few dB improvement.

How much are you over the emissions limit by?

Also, lab time can get expensive. Can you get some other ‘Debug’ testing done? Maybe ESD (could be an issue with user interface and SD card slot) and conducted interference (could be an issue with Ethernet port)? Would be very annoying to spin board for emissions issue then find ESD issues you could have fixed at same time.

Oh, yes, an applicable ESD story. The product I’m developing uses a flexible ferrite sheet for RF reasons. It’s allegedly an insulator.  But when you hit it with ESD, it conducts the ESD strike! I think it’s made of tiny ferrite lumps in a polymer carrier, and ESD jumps from lump to lump.

This resulted in ESD getting into an analog circuit some centimetres away from the strike, which was confusing.

[T3sl4co1l]

Heh, good point.  Ferrite itself has a modest dielectric constant (on top of being a mediocre conductor), makes sense.  Even if the composite material isn't a conductor (at least at normal voltages), it's still got a modest dielectric constant.  And yeah, probably broke down at high voltage.

Tim

[KE5FX]

Stitching is N/A on a 4 layer board without top and bottom pours

Good point there as well.  Boards without extensive top/bottom copper fill coverage scare me.  Arguably to an irrational extent, but still...  I don't like to remove copper without a good reason.  Why decline the offer of free shielding?

[floobydust]

I had the same issues as OP on a build using NXP processor with external SDRAM, 6-layer board. Basically, I found the CPU was spewing out a lot of EMI in the FM band, it even made out on the line cord as CM conducted emissions 

I tracked the FM carrier down to the SDRAM (auto) refresh clock. Those peak currents are very high, easily 200-400mA depending on the SDRAM size/speed and core voltage. On the bus, it's a few V/ns rise-times, so the transceivers are also switching hard.
So (my theory) the high current spikes on the CPU's address/databus seems to make its entire silicon "dirty", where other I/O something like RESET unexpectedly has a 100MHz signal present.

To fix it, I had the guy redo the PCB layout. Moved the SDRAM closer to the CPU, bus traces were not the proper impedance, beefed up the ground plane connections and upsized decoupling capacitors with pcb traces/vias support for higher current.
I added the usual series resistance on all CPU I/O pins that went anywhere significant, 47-220ohms is common on consumer electronics. As an RC filter rolls that off any high-frequency mischief coming out of a CPU. The C is either the next component, or added a few hundred pF after the resistor i.e. serial data at 115kbps was not bothered but no 100MHz drama making it out to the serial transceivers which could then pass it to external cables.
The product then passed EMC but it was a lot of work. Literally, every CPU pin I had to consider where it went and the consequences of high frequency EMI being present.

[prasimix]

I wonder if anything's resonating around 108MHz.  Could that plane under the MCU be doing it?  Or the plane around it, which is heavily cut up by the MCU plane and signal traces around it?

I'm not sure that is a problem, since when we slowed down SDRAM clock to 72 MHz the same things happen on that frequency. Ok, there is a still chance that some parts resonate at 108 and another on 72 MHz

[prasimix]

I had the same issues as OP on a build using NXP processor with external SDRAM, 6-layer board.

Thanks for this info, so i won't think jumping on a 6-layer will solve things on its own. I will have to concentrate on redesigning the existing 4-layer PCB and the result will become here. I believe that more pairs of eyes will find it easier to find potential sources of problems.

[prasimix]

How much are you over the emissions limit by?

Measurements with antenna oriented horizontally:



... and vertically:

[T3sl4co1l]

Pictures of testing setup?

It's not surprising that horizontal polarization is worst (assuming this was tested in a horizontal orientation as pictured), but it's interesting that vertical rejects most of that wideband noise except for the clock tone.  What would be radiating that?

I wonder if anything's resonating around 108MHz.  Could that plane under the MCU be doing it?  Or the plane around it, which is heavily cut up by the MCU plane and signal traces around it?

I'm not sure that is a problem, since when we slowed down SDRAM clock to 72 MHz the same things happen on that frequency. Ok, there is a still chance that some parts resonate at 108 and another on 72 MHz

By "around", I mean it might be damped enough to act as a wider bandpass.  Multiple resonances is another possibility, yup.

Tim

[prasimix]

I have just a few, here you can see antenna in vertical position, and used Keysight EMI receiver:

[T3sl4co1l]

Okay but those are 100 and 50 pixels respectively of the thing I actually wanted to see.

Tim

[prasimix]

Sorry, that's all what I have.

[KE5FX]

It would sure suck if it turns out you're actually measuring the laptop, which might have 'theoretically' passed testing at some lab in China which most assuredly was totally aboveboard. 

The last time I was in a test cell, there was a convenient platform for PCs and other ancillary gear on the floor beneath the turntable.

[prasimix]

I didn't notice anything "Made (cheap) in China" in that lab. Computer is brand name (DELL or Acer, cannot remember) and yes, to be completely sure we made measurement when it was only turned on and it is well below Class B as it should be.

[prasimix]

I started working on a new PCB. The first attempt was to bring SDRAM as close to the MCU as possible. However the pins on the MCU assigned to SDRAM do not appear to be optimized for such a setup. I continued to move SDRAM to the bottom layer. After several attempts to route with different orientations of SDRAM versus MCU I came up with a case that seems pretty good to me. I managed to route all traces to be 20 +/-0.5 mm with the exception of two: RAS and WE (CS). I only used top and bottom layer, 4-layer PCBs. So far, all decoupling capacitors and all traces between MCU and SDRAM have been positioned.
I'm not sure if I can use serpentine for address lines. I know they can be used for data lines and they should not be used for control and clock signals. I have not used more than one via per route.

Top and bottom layer detail:



Bottom layer only (with top silk mask for better visibility of MCU position):



SDRAM wire lengths:

[Dulus]

Precise length tuning at these frequencies/trace lengths are really not usefull at all.
±20% would easily suffice i would say.
I would go for the highest ground coverage possible.

Maybe you can place the chips as in the attached drawing. Seems to me that most of the traces seems to benefit from it.
MCU is red, RAM is blue =D

From previous posts, it seems that you've sorta kinda located the culprit traces.
You can try RC snubbers at the trace ends, near the chip pins.
Since the traces are not impedance controlled, and the input impedance of the chip pins are not really defined, traces can ring and emit a higher amount of EMI than it normally would.
So you can "terminate" these high frequency components on those high speed pins, therefore cut the emission or crosstalk or whatever you wanna call it.
Just get a scope and go trial&error on its ass...

Best of luck.
Deniz

[prasimix]

Thanks for the good wishes, I really need a lot of luck here. I tried to go with as short traces as possible assuming it could generate less EMI. However I think the real challenge is to achieve the desired impedance of 50 Ohms. Going from top (layer 1) to bottom (layer 4) I don't see how feasible this is. With a used width of 10 mils  and the assumption that the PCB manufacturer will respect the distance between the top and ground plane (Layer 2) of 7 mils, this gives about 54 Ohms (with a width of 12 mils we would have 50 Ohms). Moving to the lower layer completely disrupts this calculation and the impedance jumps over 100 Ohms if referenced against Layer 2 (or it could be referenced against Vdd on Layer 3, too?).

I don't see how SDRAM should be set up against the MCU so that all routes are only on the top layer. This would only be feasible if all assigned MCU pins for SDRAM were on one side instead of all four.

I didn't know it was possible to use RC snubbers in cases like this. I would love to see some examples, this would help me plan their deployment. RC components I guess should be very tiny 0603 or even 0402?

[BrianHG]

Thanks for the good wishes, I really need a lot of luck here. I tried to go with as short traces as possible assuming it could generate less EMI. However I think the real challenge is to achieve the desired impedance of 50 Ohms. Going from top (layer 1) to bottom (layer 4) I don't see how feasible this is. With a used width of 10 mils  and the assumption that the PCB manufacturer will respect the distance between the top and ground plane (Layer 2) of 7 mils, this gives about 54 Ohms (with a width of 12 mils we would have 50 Ohms). Moving to the lower layer completely disrupts this calculation and the impedance jumps over 100 Ohms if referenced against Layer 2 (or it could be referenced against Vdd on Layer 3, too?).

I don't see how SDRAM should be set up against the MCU so that all routes are only on the top layer. This would only be feasible if all assigned MCU pins for SDRAM were on one side instead of all four.

I didn't know it was possible to use RC snubbers in cases like this. I would love to see some examples, this would help me plan their deployment. RC components I guess should be very tiny 0603 or even 0402?

When using a single ram chip, in the past, I've tuned and used just series resistors alone to minimize EMI.
With such a low speed ram chip, length matching is a waste of time.  The fact that all signals go through only 1 single via in you layout will keep any big timing inconsistencies in check (IE, a few signals going through 3 vias instead of 1).  I have routed 200MHz DDR, 400mtps designs in this way without any issue.  Above 600mtps was when length matching began to become important.

1 big hint, all ram chip controls and clks should have their series resistor on the same side as the CPU and close to the CPU output pin as possible.  This way, you are not conducting a really harsh transition through a length of trace and via.

For the data IO, the series resistors should go next to the IC which has the faster output data.  You should be able to scope this and measure whether the CPU output is faster, or if the ram chip data output is faster.  (It is possible to use 2 series resistors, 1 by the CPU and 1 by the ram data IO pin to absolutely minimize harsh EMI.)

This will minimize EMI coming off your PCB other than additional layout and shielding efforts.

[T3sl4co1l]

The recent build I mentioned, oh I suppose I should drop in a (poor) picture of it;



the memory bus traces range from 408 to 1337 (nice) mils in length, also with the CLK going double back to a return pin (I guess so the controller can estimate propagation delay itself?).  Probably the return clock wasn't necessary at this bus length, and can be returned at the controller.

I don't have a scope quite fast enough to measure the full waveform, but from what I can see, the waveforms aren't noisy (supply is quiet), have modest overshoot (about 20%), and little ringing.  Likely a consequence of the high trace impedance combined with pin capacitances, and the pin drivers being typical CMOS strength (30-70 ohms).  (I measured CLK with a 10x lo-Z probe, which will have some damping effect compared to the ~100 ohm traces; again, 2-layer board.)

I don't see much conducted from the cables, and as you can see, the memory is off to the side, completely surrounded by stitched ground pour.  Supplies are well bypassed (there are three 0.1's on the RAM, and three nearby on the controller's VCC and VCORE pins on that side).  Ground is nearly solid, with exceptions made for traces crossing to the far row (including the CLK return signal), and VCC.  There should be very little way for noise to go anywhere, even though it is quite a noisy location as attested by the near field probe.

Layout:



Top and bottom, transparent




Top alone




Bottom alone


Notice VCC comes from the corner of the controller chip, and "uselessly" switches layers under the bus (which happens to be most of the DQs), allowing ground to fill underneath.

I'm sure I could've optimized the bottom side routing better, perhaps even pouring ground between every trace, not just pairs.  Breaking up the large group, the four parallel traces (half of which happen to be CLK!), would be nice.  But of course, how nice that is, depends on how much it really matters; clearly the circuit is functional, and beyond that, I don't have much more I can test.  (Perhaps the overshoot is triggering ESD diode conduction, perhaps it's causing increased current consumption, or stress, I don't know.  I'd need much fancier test equipment to figure that out.)

There is a bus running around the SDRAM, just out of view, but you can see corners to the bottom-left and bottom-right.  These of course would not be a great idea to route under it (but on a 4-layer design, that wouldn't matter).


Keep in mind that,
1. We still have not confirmed why and where the noise is being conducted on your board (incomplete testing information);
2. Multiple changes have been proposed, all of which are expected to have some effect on performance;
3. You have approximately zero intent of checking all of those proposals individually -- at least I'm guessing you aren't going to spend months, and tens of thousands of dollars, testing a prototype for each change.

It is quite possible that your initial change has already solved the problem to an adequate degree, and all the rest of this is just masturbation.  (Which makes this a good kind of thread for people like me to brag about our glossy routes and stitched planes, but not a very productive thread otherwise...)

Tim

[BrianHG]

These 2 sizes of 4 in 1 were optimum in my designs.
I would use the width matching the QFP/TSSOP pin spacing.
Obviously you might use a different values.

Chip Array Resistors example

Larger arrays of 8 resistors exist, but, I found 4 the optimum.

[prasimix]

Keep in mind that,
1. We still have not confirmed why and where the noise is being conducted on your board (incomplete testing information);
2. Multiple changes have been proposed, all of which are expected to have some effect on performance;
3. You have approximately zero intent of checking all of those proposals individually -- at least I'm guessing you aren't going to spend months, and tens of thousands of dollars, testing a prototype for each change.

It is quite possible that your initial change has already solved the problem to an adequate degree, and all the rest of this is just masturbation.  (Which makes this a good kind of thread for people like me to brag about our glossy routes and stitched planes, but not a very productive thread otherwise...)

It will be very good if you are right and that just fixing the MCU power supply fixes the problem, especially because I don’t have the time and money for multiple new iterations. Maybe I should proceed with two PCB variants: with corrected +Vdd on L3, and maybe another one with relocated SDRAM.
I tried with H-probe to sniff over MCU and SDRAM. MCU is significantly more noisy. This is what a typical spectrum looks like:



SDRAM seems more "defined" which I guess is to be expected:

[T3sl4co1l]

What's running, by the way?  In my case I have continuous SDRAM access because it's scanning a raster, and so also everything after that (the interface driver and display panel, but those are LVDS so the emissions are quite modest).  But I don't have any display updates written in yet so the MCU interface isn't doing anything (besides supplying clock to the controller's PLL), so I don't see anything on that cable.

Is that doing basically the same thing..?  Didn't look up your MCU, but it looks to be a similar sort of thing, raw parallel RGB to the panel, via controller peripheral?  With direct access (DMA or otherwise) to the SDRAM, I would suppose?  If so then that should be reading lots of data out, with corresponding sidebands visible around the SDRAM.  Or at least subharmonics for address lines (which are towards the end pictured, I think?).  It was initialized and running, right..?

Was that corner of the MCU the loudest, or anything?  (Or the SDRAM for that matter, too.)  How does it vary (intensity and spectrum) over the chip?  What else is running, what sorts of functions, or peripherals?

Any other spots on the PCB, top or bottom?  Might use a smaller probe to sniff up close to bypass caps for instance, or some traces, see if there's anything suspicious.  Not that bypass caps shouldn't be noisy, of course the ones close to the chips should be carrying a fair amount of signal currents; but it would be peculiar if signal currents are found at a distance, in unexpected places.

Tim

[prasimix]

What's running, by the way?  In my case I have continuous SDRAM access because it's scanning a raster, and so also everything after that (the interface driver and display panel, but those are LVDS so the emissions are quite modest).  But I don't have any display updates written in yet so the MCU interface isn't doing anything (besides supplying clock to the controller's PLL), so I don't see anything on that cable.

Is that doing basically the same thing..?  Didn't look up your MCU, but it looks to be a similar sort of thing, raw parallel RGB to the panel, via controller peripheral?  With direct access (DMA or otherwise) to the SDRAM, I would suppose?  If so then that should be reading lots of data out, with corresponding sidebands visible around the SDRAM.  Or at least subharmonics for address lines (which are towards the end pictured, I think?).  It was initialized and running, right..?

It's doing "nothing" ... SDRAM is used as frame buffer and this picture is displayed on the TFT screen:

[prasimix]

Was that corner of the MCU the loudest, or anything?  (Or the SDRAM for that matter, too.)  How does it vary (intensity and spectrum) over the chip?  What else is running, what sorts of functions, or peripherals?

Any other spots on the PCB, top or bottom?  Might use a smaller probe to sniff up close to bypass caps for instance, or some traces, see if there's anything suspicious.  Not that bypass caps shouldn't be noisy, of course the ones close to the chips should be carrying a fair amount of signal currents; but it would be peculiar if signal currents are found at a distance, in unexpected places.

This probably asked for more trained eyes and hand. The spectrum and intensity slightly vary over the different side of the MCU. On SDRAM side there is almost no fluctuations. If we go back to the beginning where I found that it is the communication with SDRAM that makes a lot of noise, it turns out that the main cause is really a bad MCU's power rail.

[prasimix]

Yesterday I completed two new MCU modules that have already been discussed. The first has only MCU +Vdd corrected, and the second has SDRAM placed beneath the MCU.

If measured at the same point as on the existing MCU module r2B4 the first correction does not seem to have helped: 108, 324 and 540 MHz are still very pronounced:





However, in the case of the second correction when the SDRAM was set beneath the MCU, there was a significant improvement:







Of course this still does not say whether we are within the radiated emission limit or not. We'll find out soon in the lab.

[prasimix]

Today we passed radiated emission with a corrected MCU module r3B3 that has SDRAM beneath the MCU. This is what the worst case with max. load looks like for the antenna placed horizontally:



This is what it looks like if the antenna is placed vertically:

[void_error]

I'm wondering if the EMI issues for the first board were caused by the return currents through the ground plane not following the signal traces (large loop antenna?). I'm no EMC expert (or any kind of expert for that matter) so take that as a question.  I'm asking this since I'm in the process of routing (or shooting myself in the foot) a similar STM32F7 board with two SDRAM chips and although it doesn't need to pass any EMC tests (small batch for personal use) I want to make sure It doesn't spew out tons of radiation. Don't want to hijack this topic so I'll probably start another one when I have it done.

[prasimix]

Hard to say anything. I'm not even close to be an EMC expert. Ground plane wasn't broken on the previous version, but Vdd for MCU was. I made another prototype with that correction, but it still behave much worse then prototype with SDRAM beneath MCU.

[void_error]

To be more specific, I was comparing the layout T3sl4co1l posted (where the traces from the controller to the RAM chip are pretty much straight) to your first board where the top layer traces from the RAM chip to the MCU look like the letter 'L'. I'm curious whether that makes a difference. With the really messy pinout of pretty much every STM32F series micro it's nearly impossible to get a clean layout.

[T3sl4co1l]

Nah, topologically speaking, an 'L' over a ground plane is practically a straight line.  It'll have some different emission (gain and pattern) at very high frequencies (i.e., where the leg of the 'L' becomes resonant), but at low frequencies (where it's electrically short) it really doesn't matter.

Willing to bet, in my case, the fact that the traces are so much higher above the plane, and that the plane is as cut-up as it is, dominates over trace length or shape.

Tim

[SiliconWizard]

Willing to bet, in my case, the fact that the traces are so much higher above the plane, and that the plane is as cut-up as it is, dominates over trace length or shape.

I agree, and would personally put all the power planes "slots" as the first source of problems. As it is they don't even really look like proper power planes anymore.