1
\$\begingroup\$

I have a complex EMI problem.

There is a RPi Compute Module along with a LAN9512 and GSM modem (M66).

Layout guidelines are strictly following the datasheets' recommendations, I don't think there is anything can be much better around them on the layout.

Now RPi and LAN9512 are connected via USB differential pairs, but when GSM modem is active (i.e. connects to network, receive call etc), the LAN9512 disconnects from usb and comes back only after a full reboot.

This is the main issue which I'd like to solve here.

Console log of the issue:

kernel: [   10.172712] usb 1-1-port1: disabled by hub (EMI?), re-enabling...
kernel: [   10.172750] usb 1-1.1: USB disconnect, device number 4
kernel: [   10.173135] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-‎20980000.usb-1.1, smsc95xx USB 2.0 Ethernet
kernel: [   10.175308] hub 1-1:1.0: hub_ext_port_status failed (err = -71)
kernel: [   10.175332] usb 1-1-port1: connect-debounce failed
kernel: [   10.192773] usb 1-1: Failed to suspend device, error -71

What could also help:

I'm seeing that 3.3V and 1.8V power lines do have a square signal which is 400mV higher when the GSM communicates (square length is 500-600us, dV is 300-400mV): 1.8V power when GSM active

On the board I have DC generators:

  • 5V - MP2359
  • 4.1V - MP2359
  • 3.3V & 1.8V - PAM2306 (common)
  • 2.5V - AP7115

They are wired like this:

18V input DC
 -----> 5V  -----> 3.3V ----> 2.5V 
            -----> 1.8V
 -----> 4.1V

GSM modem is powered from 4.1V so it is actually separated from everything else.

These spikes (squares) are only presented on 3.3V and 1.8V which is regulated by the very same PAM2306. Neither on the 2.5V nor the 5V does have these spikes. Also the 4.1V which is actually for the GSM does NOT have these spikes either. There are 100uF, 100nF, 33pF and 10pF decoupling capacitor on the 4.1V rail.

PAM2306's layout (on the top right there is the 1.8V at the inductor's right side): Please note that this layout is the recommended by the datasheet. I know those lines going around look strange though. PAM2306

I also tried adding a 100uF decoupling to the 3.3V rail, but did not help.

One thing should be good to know here: could these spikes cause the USB disconnect?

UPDATE1:

I have removed PAM2306 power module and replace with 2 MP2359 for the 3.3V and 1.8V.

Now the boards seems more stable, however the USB disconnects after connecting the GSM:

# pppd call gprs
... lot of pppd messages ...
pppd[2079]: primary DNS address a.b.c.d
pppd[2079]: secondary DNS address a.b.c.d
usb 1-1.1: USB disconnect, device number 3
smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-20980000.usb-1.1, smsc95xx USB 2.0 Ethernet
smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup

So as you can see, after getting GPRS IP addresses, the ETH suddenly unregisters itself. After changing those power modules the previous 'disabled by hub' message went away so the situation is now better but not perfect.

What would you recommend?

UPDATE2

After an hour without trying to dial up GSM, the USB disconnected from the PI. So not the power rails were the root of my problems.

\$\endgroup\$
  • \$\begingroup\$ You use a very high frequency hobbyist computer for toy applications and then wonder why EMI is a problem? \$\endgroup\$ – Lundin Apr 24 '18 at 8:40
  • \$\begingroup\$ I would look at the power distribution. The GSM modem draws up to 2 Amps pulses when transmitting. If you PSU for the GSM modem is weak, the current pulses might end up on your other power rails. It's hard to say from the information given. Try adding a couple of low esr caps close to to the GSM modem power pins. 1000uF or so. \$\endgroup\$ – Peter Karlsen Apr 24 '18 at 8:44
  • \$\begingroup\$ What you have here is really strange. You will have higher supply voltage when a module draws more current.(!?!) It is hard to imagine, so there has to be something else. Is the grounding good enough? If you probe the grounds at different points are they the same? What you has shown resembles an I*R drop for a constant current (just the sign is wrong!). Maybe the grounding of the reference of one of the regulators are not good enough, and the current of the module modulates it. This is my best guess, since dV is very high in the pic. I would also look into the supply waveform measurement. \$\endgroup\$ – Horror Vacui Apr 24 '18 at 9:25
  • 2
    \$\begingroup\$ Not much in the way of ground stitching on that power converter and there are some stupidly big loops, I would look to that, especially if the rest of the board is also like that. Then, common mode chokes on the USB bus lines, but without a LOT more detail it is hard to say. I would also have a look at your scope probe technique, those three inch black 'ground' leads are aerials at anywhere much over DC, and you may also be seeing epic amount of ground bounce if the ground connection goes via a tiny trace somewhere (Differential probing will help see if this is an issue). \$\endgroup\$ – Dan Mills Apr 24 '18 at 9:52
  • \$\begingroup\$ How are you measuring the power rails? Your probe may be acting as an antenna too,and picking up RF, if it's anywhere near the high fields from the GSM modem... \$\endgroup\$ – tomnexus Apr 24 '18 at 10:07
1
\$\begingroup\$

This problem has nothing to do with "EMI" in normal electrical engineereng sense. This is a problem with power supplies.

According to M66 GSM data sheet, the modem needs 1.6 A during transmission phase.

enter image description here

However, according to MP2359 datasheet, the power output is no more than 1.2 A per channel. So your power supply is 50% underrated for the application peak current (while the average is probably met). The internal drop in M66 likely causes it to disconnect from USB, and full modem reboot is needed to function again.

To get some traction, you might need to use HUGE capacitance, maybe 10-20 100uF ceramic caps in parallel on 4.1V rail to alleviate the problem of high peak currents.

P.S. I wonder when posters would start specifying links to datasheets for the involved components, and actually start reading them before posting questions?

\$\endgroup\$
  • \$\begingroup\$ Thank you, and sorry for not linking the sheets. I have a 100uF ceramic cap on the 4.1V. I would think that MP2359 can handle this modem with this cap. On the scope I can see a sharp straight line during the whole GSM operation on the 4.1V rail. \$\endgroup\$ – Daniel Apr 24 '18 at 21:12
  • \$\begingroup\$ @Daniel, Their recommended power supply (Figure 5) uses 470 uF capacitor. What you see is really strange, since even the datasheet (Figure 3) shows Vdrop explicitly. Try to beef-up the rail by soldering a bunch of caps on top of each other. if space is limited. \$\endgroup\$ – Ale..chenski Apr 24 '18 at 21:31
  • \$\begingroup\$ Calculating the RC Timeconstant for the 100uF it would take around 256us to empty if the 4.1V stops. The spike you mention here is 577 us, but since the 4.1V does not stop it would take more time to empty. Of course, it's not ideal though. What is more important: the false spike is not on the 4.1V, it is on the 3.3V and 1.8V rails. Also the modem works fine, it is not connected via USB, but serial. Only the Ethernet controller is connected via USB and that keeps disconnecting. \$\endgroup\$ – Daniel Apr 24 '18 at 21:40
  • \$\begingroup\$ @Daniel, then you need to tell a bit more about your design. Paspberry Pi is proprietary design. Are you embedding RPi into some other board with M66, or what? How do you connect it? Bumps on unrelated rails might indicate ground bounce problem in your layout. \$\endgroup\$ – Ale..chenski Apr 24 '18 at 21:55
  • \$\begingroup\$ @Daniel, with 100 uF cap and 1.6 A load current, the voltage would drop by 1V in 62 us. I = C * dV/dt. Dropping below 3.3 V would kill M66 functionality, according to the datasheet. You need to check your measuring technique. \$\endgroup\$ – Ale..chenski Apr 24 '18 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.