G400 Ground Bounce?

NETMF & Gadgeteer
1

This post is in reference to the reboot events described by @ Gene at https://www.ghielectronics.com/community/forum/topic?id=19245

Thinking brown outs could be a potential cause for Raptor reboots, I connected a scope to look at 3.3V and 5V lines. After probing around, I discovered that the lines have significant noise events associated with digital logic communication.

Test 1:
Scope trace: SPI_bounce.png
[ul]CH1: X1-P9 (SCK)
CH2: X1-P2 (3.3V) (AC coupled)
100MHz scope & probe bandwidth
Analog devices CN0254 attached w/18in 24AWG wire (long for SPI, yes)
Powered via 12V into USB Client DP Module
GHI supplied 10-pin ribbon cables[/ul]

Wondering if a similar behavior is present on other logic lines, I tested I2C…Similar result
Test 2:
Scope Trace: I2C_bounce.png
[ul]CH1: X2-P9 (SCL)
CH2: X2-P2 (3.3V) (AC Coupled)
GPS powered and sitting on I2C bus (24AWG twisted pair)
Powered via 12V into USB Client DP Module[/ul]

Afraid I may be tracing a Red Hearing because of a ground loop present between the G400 and scope, I grabbed a battery powered scope to make a fully isolated measurement. The same noise was present (see I2C_battScope.jpg).

The noise events happen even when no devices are present on the buses (i.e. measuring on directly off a breakout boards).

Grasping for straws I added an additional 100uF tant cap in parallel to C31 on the G400, but no observable change in behavior was seen.

Because it appears on both 3.3V and 5V, is this signal likely on GND? Assuming sufficient capacitance exists to hold the buses up through logic transition, what could be the cause of this? High impedance GND? Possibly caused by a flaky connector/ribbon cable?

Back to the original question: could this be causing Reboots? No reboots were seen during this testing, but perhaps with lots of devices connected and communicating the voltage buses see enough abuse to reboot the Raptor? Obviously the noise on the DC lines is bad, but we’re unsure if it’s actually the problem that’s causing the reboots.

EDIT:typos.

2

The oscillation I am seeing on the signal is normal, especially when no load is connected. When the signal goes from a state to another, a lot of energy if pushed into the transition, causing the signal to overshoot and then it goes into oscillating a bit before it settles.

Internal memory buses are tuned with resistors to compensate for this. With billions of memory access cycles, it is easy to see if the board would reset due to a bad design on the memory bus.

3

Looking again at your post, what you see on power doesn’t make sense but you can wire a bench power supply and see if the board would run better.

Are you connecting to ground and power right onto the SoM pads?

4

@ Gus - I did run the tests with the Raptor powered directly (3.3V) through 22AWG wire and a 4.5A bench top supply. The same oscilations on the 3.3V bus were seen.

Powering the SoM directly and bypassing the Raptor is possible, but is a bit of work as VCORE and VDDIOM are generated on the Raptor, and not the SoM.

As I mentioned, it’s also not clear to us (myself and @ Gene) that such oscillations are actually the root of our seemingly random reboot. Our prototype system has has significatnly more IO than was used to generate those scope plots (we’re running I2C, SPI, and several asynchronous RS232 connections, at varying baud rates).