Paging EEs and XMega Veterans! - Strange Failures with XMega256A3U

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry for the "click-bait-ish" title. I'm having a series of random failures on a custom board carrying the ATXMega256A3U and I'm having a devil of a time tracking them down. I'd like some general advice on where to go in troubleshooting. Here's the story (as concise as possible):

 

  • Custom PCB with ATXmega256A3U, XBee 900 Pro HP, I2C to UART bridge, RS232 transceiver chip and 3 switching regulators providing 3V3, 5V0 and 9V0 voltage levels.
  • Primarily a data ingestion / fusion board. It reads serial data from several different off-board systems/sensors, fuses them into a single data packet and then transmits it via the XBee.
  • XBee is setup in transparent mode and communicates via 115200 baud UART. Data packets are small (few hundred bytes) and have low rep rate (1Hz)
  • I have tested 6 boards against 3 different systems. The failures are not consistent with themselves and not consistent against a specific system of sensors (i.e. I don't believe it's a malfunctioning sensor killing boards).

 

At first, everything works exactly as intended. After some amount of time (we haven't been able to nail down exactly when - sometimes it works continuously for hours, including multiple power cycles, sometimes failures occur after 1 or 2 power cycles!) various problems with the micro crop up. A few examples:

 

First failure was the pin driving the reset line for the XBee. I had the XBee reset wired to a tactile button for manual reset and also to PA4. I had PA4 configured as a "WiredAND" to protect it in case someone pressed the reset button. No one did, in fact it was installed in such a way that the button can't be pressed even by accident. After a few power cycles, the XBee got stuck in reset. Upon examination, I disconnected the reset button and I determined that PA4 was latched low. When I re-flashed the micro, it pulled it high and it worked... for about 10 minutes and then it seemed like the pullup was disconnected because I could watch the voltage on the pin slowly bleed down to fuzzy and then 0. Here's the really strange part: I changed the PA4 configuration to be a totem pole drive and commanded it high. Everything worked and continued working for months before it suffered a UART problem (see below).

 

Next failure was on a different board. This time, the problem was with the PORTD UART. The RX pin was idling low instead of idling high. Maybe "idling" isn't the right term - it was actually being pulled low by the micro. There is a 1K resistor in series with the UART pins and the other side (the I2C to UART bridge) was banging out the signal exactly as it should be but all 3.3 volts was being dropped across the series resistor. I replaced the board.

 

The board with the XBee problem eventually had a similar UART problem. This time it was the PORTC UART. The RX pin seems just fine and idles at 3V3. The TX pin also idles at 3V3 but doesn't transmit (consistently). This one is really weird. After I removed the board from service, I took it to the bench to diagnose. I verified that it wasn't responding to queries over the wireless link and flashed a debug program that just transmits ASCII 'U' to the XBee. I saw the U come through wireless sporadically. I put a scope on it and verified that sometimes it was transmitting and sometimes it would idle high. I also noticed a green LED connected to the power rail would occasionally "stumble" while the micro was transmitting 'U'. It was so infrequent that I wasn't able to capture anything on the power rail with my scope. This intermittent behavior continued for about 15 or 20 minutes as I debugged. Eventually, it stopped all together. I am able to program the micro, set fuses, etc. but it doesn't seem to be executing code directly. I have debug LEDs on PORTR and PORTC. Neither of those are responsive (i.e. I flash a simple program to light them and nothing happens, and yes the pins are properly configured for output, etc - the test program works on a new board just fine). 

 

I ran the system with a scope on the 3V3 rail for about an hour to see if there were any spikes that could be damaging the chip, but nothing...

 

There have been other failures similar to the above, typically with a UART that just stops responding, followed by the micro crapping out and none of the pins responding.

 

Any ideas???

 

 

A little background: I've designed and now produced 500+ boards using various ATXMega chips. This is the first time I've seen these problems. I try to follow best practices in PCB layout and keep my UART/SPI/I2C/PDI traces matched in impedance, even when running at fairly low baud rates. The only difference on this board versus my other ones is that the decoupling caps for the micro are on the bottom of the board while the micro is on the top of the board. I really don't think this has anything to do with it; I know some people get fussy with these but I'm using a fairly large via and it's a 4-layer board with power and ground planes. The decoupling caps are right on top of the pins they feed, just on the reverse side.

 

Attached is a (somewhat messy) schematic of the micro connections. Not sure how useful it is...

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Strange behavior  like that, especially after a time delay, is often associated with stack overflow or a buffer over-run.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Strange behavior  like that, especially after a time delay, is often associated with stack overflow or a buffer over-run.

 

Jim

 

Thanks Jim - I assumed that a hardware reset would make the problem go away if it was a stack overflow. Is that not true? These problems (once they come) stay, even after power cycles and flashing new code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It sounds like appendicitis.  Take out the appendix!

 

Oh wait, time to change gears...

 

I know how frustrating such problems can be...

 

A couple of thoughts, which may or may not be helpful.

 

Regarding the Reset pin failure, using a Wired And config sounds like it should work well.  I've not tested that functionality, I've usually just put a current limiting resistor in the system in case there is a conflict.

Clearly the voltage on that pin shouldn't float anywhere.  The Internal or external pull-up should hold the pin high unless the either the micro or the PB Switch are actively pulling it low.

If you are using the internal pull up resistor I'd carefully check that you have in fact enabled the pull up resistor.  If you have, and the pin still floats, then that pin's driver has likely been damaged...

 

On the second board mentioned, with the USART RxData pin being actively driven low by the micro, It sounds like the serial data was being transmitted correctly, but the pin was configured incorrectly.  Obviously a Receiving (Input) pin should be in a high input impedance state, with only the external driver controlling the signal level.  Perhaps the bus keeper was inadvertently enabled?  (Again, I've not worked much with this feature on the bench, so it's just a thought.)

 

Board #3, PortC's USART.  You mention that the system was sometimes transmitting the test "U", sometimes not.  I think you said that the intermittent transmission was when testing the micro's TxData pin, not the output from the XBee.  For debugging this you want to ignore the XBee, at least initially.  Recall that the XBee is a smart module, has its own buffer, and depending upon its config it will automatically retransmit data.  That can be good, can be bad, but can have an upstream effect on losing incoming data from a buffer overrun.  If you were monitoring the micro's TxD pin, then obviously with a simple test program the data should be continuous.  The system shouldn't stall, not even a little bit!

 

So, assuming the test program is small, and doesn't have a stack problem, one would have to consider: Watch Dog Interrupt is firing, stalling the system, and the program is re-starting, or the power supply is brown-outting, (sagging), and the micro is re-setting, and restarting the program, or an interrupt is firing and taking time away from the USART data stuffing routine, or an External interrupt, (USART, SPI, PinChange, ...), is enabled, and firing, and there is not external hardware currently connected to the pin, and not pull up holding the pin in the desired state, as the interrupt enabled input pin is floating and bouncing up and down now and then, or... (those are the main possibilities that come to mind at the moment).

 

Next:  Time to also review your power supplies and their design, and the specific Cout capacitors used, (their ESR value, to be specific). 

 

My first Xmega128A boards were hand soldered, and I didn't have much experience soldering high pin density chips.  It was a challenge.  I made a few of those boards, and one, I think, fried itself from residual solder flux under the chip...  Two of the boards worked for a while, and then would start drawing high current, and the Xmega would get hot!  power off.  Wait a bit.  Power up, and in a bit the board's current would climb and the chip would get hot...  Repeat... 

 

It turns out the 3.3 V regulator was warming up, and then oscillating.  Vout wasn't tightly regulated when the power chip oscillated, and when Vout was high the poor Xmega was getting cooked.  The culprit was a poorly selected Cout cap on the 3.3V regulator, which was much more sensitive to such variables than was the 5 V regulators that I was accustomed to using.  I fried two Xmega boards, which were challenging for me to painstakingly assemble,  before I tracked down the cause.  Lessons learned...

 

So, sporadic errors with just simple test programs would one to look closely for hardware issues, plus the other ones mentioned above, (interrupts, brown-outs, Watch Dogs, etc.).

 

Know, also, that a bad power supply can fry anything on the micro, perhaps accounting for some of the other failures?

 

Lastly, recheck that each Vcc and Ground pin are connected to their appropriate rails, and are appropriately by-passed. 

 

Things like the micro resetting are easy to spot if you simply put a flash this particular LED 5 times on startup in your start up routine.    Then investigate why the micro is re-starting, if it is.

 

Also, the green power LED occasionally stumbling is a major clue and a major problem.  That, also, just shouldn't happen with a good power supply, operating in spec.  Something had to majorly overload the rail for you to see the LED dim.  So, first question here is this: Is the power supply and the voltage regulator able to supply adequate current when everything is fully loaded?  Put an ammeter in series with the power supply V+ input, or the rail, to watch for a dips.  If the XBee detects a transmission error is it automatically switching to a high power mode?  Can the regulator handle the max load, continuously, without overheating?

 

Boards that run correctly when cold and then have problems after running a while are sometimes experiencing a voltage regulator that is overheating and going into t thermal overload and current roll back state.  Depending on the regulator, and the problem, there could be a brown out and the micro could reset, or it could lock up until power is cleanly re-cycled.

 

When simple test programs, (e.g. transmit a "U"), fail, one has to look closely at confirming the I/O pins are correctly set up, and validate the hardware, as obviously the project's main software has been taken out of the equation. 

 

Enough rambling.  Perhaps that will spark an idea or two to help you track down the problem.

 

JC

Last Edited: Fri. Nov 3, 2017 - 11:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, be on the lookout for pins that appear to be soldered, but really aren't (...but I see solder on that pin)...A slowly developing hairpin crack in a solder joint can play havoc with your board ...and sanity.  put it on a vibration stand (or perhaps on a table that's being hit with a hammer)...see if that leads to a faster issue.

 

 

  

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Attached is a (somewhat messy) schematic of the micro connections.

Unreadable.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TMS8C8 wrote:
I also noticed a green LED connected to the power rail would occasionally "stumble" while the micro was transmitting 'U'. It was so infrequent that I wasn't able to capture anything on the power rail with my scope.
A digital scope is a sampling instrument (sample, compute, repeat) such that the compute time duration could be long relative to the sample time duration; the spec is waveform rate.

Some scopes have a good waveform rate and also a DPO mode to emulate what the analog scopes did (phosphor)

Might try monitoring that power rail with an analog scope.

TMS8C8 wrote:
Any ideas???
EOS and stability issues due to EMI assuming ESD and EFT are not present.

A 250mW ERP 900MHz ISM transmitter with 215mA transmit current on the same power rail (3V3) as the XMEGA.

A 2W ERP transmitter is on an approximate next band to 900MHz ISM and these are known to destroy some electronics (your cell phone)

The XBee's ERP is enough to upset some electronics, and if its DC power return is underneath the XMEGA (PCB layout is 3V3 SMPS, XMEGA, XBee) then the XMEGA's 32MHz RC oscillator may jitter enough to cause erroneous actions.

Most regulators are conditionally stable.

The very good in-place stimuli for the 3V3 SMPS is the XBee and the XMEGA (XMEGA are known for upsetting voltage regulators)

There's a reason for the 10 micro-H inductor to an XMEGA's VCC.

Might substitute a battery for the 3V3 SMPS output and see if that helps redirect where to look for the/a cause.

Evaluate the 3V3 SMPS's stability by either a strong step load or better is a low frequency network analyzer (gain margin, phase margin)

Could cut the ground plane to section direct return current though that's likely a no-go with a 4-layer PCB; instead, reduce current density by tacking a ground plane on top of the XMEGA's package (copper tape, tack to all GND pins)

Likely need to evaluate the PCB's layer stack and layout.

For the XBee, confirm the recommended PCB layout; may need some ground via stitch to reduce the XBee's return current density.

 

XBee ERP -

EMI can be apparent via a device's ESD diodes (rectification) causing an input offset voltage or current being injected into the device's die.

Excessive die substrate current will upset the device's oscillators.

Excessive current through the ESD diodes will cause these to leak then short.

Might break-out XMEGA CLKper through a pin, a 1KR resistor, 50 ohm coax, very short coax shield to nearest XMEGA GND pin, 50 ohm scope input and monitor CLKper simultaneously with VCC.

GND monitoring can be direct into a scope's 50 ohm input (current between a BNC connector's center pin and shield or solder the cable direct to the ground plane)

Some regulators can supply a 50 ohm scope input else it's the same 1KR coax probe.

TMS8C8 wrote:
The only difference on this board versus my other ones is that the decoupling caps for the micro are on the bottom of the board while the micro is on the top of the board. I really don't think this has anything to do with it; I know some people get fussy with these but I'm using a fairly large via and it's a 4-layer board with power and ground planes. The decoupling caps are right on top of the pins they feed, just on the reverse side.
The length is longer even with one large via instead of multiple skinny vias.

Increased series inductance will move the bypass capacitor's resonant frequency.

Might tack the next magnitude down value capacitor direct to each XMEGA's VCC and matching GND pins then see if that helps.

If there was a ground and power plane layer swap between the functional PCBA and this new PCBA then that may be a hint.

 


https://www.digi.com/products/xbee-rf-solutions/sub-1-ghz-modules/xbee-pro-900hp#specifications

Tektronix

Mixed Domain Oscilloscopes

MDO4000C Series Datasheet

https://www.tek.com/datasheet/mixed-domain-oscilloscopes-0

(Specifications tab)

...

 

Maximum waveform capture rate

>340,000 wfms/s in FastAcq acquisition mode on 1 GHz models

>270,000 wfms/s in FastAcq acquisition mode on 200 MHz - 500 MHz models

>50,000 wfms/s in DPO acquisition mode on all models.

 

...

http://www.avrfreaks.net/forum/xmega-sram-slow-turnaround-solved-glitchy-power-supply#comment-1028546

Texas Instruments

TI E2ETM Community

Blogs

Power House

Testing power supply: Measuring stability

by

Apr 24, 2013

http://e2e.ti.com/blogs_/b/powerhouse/archive/2013/04/23/testing-power-supply-measuring-stability

YouTube

Texas Instruments

Engineer It - How to test power supplies - Measuring Stability

Mar 26, 2013

https://www.youtube.com/watch?v=HJSaIqWzM9w (7m7s)

via https://www.edn.com/design/power-management/4412230/1/Testing-a-power-supply---Stability--Part-three-

Digilent

https://reference.digilentinc.com/learn/instrumentation/tutorials/ad2-network-analyzer/start

When building circuits, we often need to determine how the circuit will respond given certain inputs. ...

http://store.digilentinc.com/analog-discovery-2-100msps-usb-oscilloscope-logic-analyzer-and-variable-power-supply/

Murata

What are impedance/ESR frequency characteristics in capacitors?

2/14/2013

http://www.murata.com/en-us/products/emiconfun/capacitor/2013/02/14/en-20130214-p1

 

Edit: YouTube

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sun. Nov 5, 2017 - 06:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you all for your help, especially DocJC and gchapman for taking the time to respond with such detailed replies. 

 

I left the system running all weekend with a 500 MHz DPO on the 3V3 rail with the board supplied by the actual power supply used in the final configuration. I've got the scope setup with a pretty tight window trigger so I'm hoping to catch some jitter that will prove illuminating. I will dig in more tomorrow but it sounds like I'm on the right track looking for something on the power rail?

 

DocJC - the code I'm using ran on an older generation of the board with no issues, so I don't think my problems are software related (although I don't rule out anything for certain. I'm capable of just about any bonehead mistake you can imagine). The test code is the same config / initialization pieces, I just comment out the main body and stick in whatever simple code I want to test (like transmitting U). I do have different color LEDs to help me visualization when the software restarts. I can't go into too many details because this is a paying job but the older generation of the board had the same components on it. The only thing that changed was the arrangement and the addition of a few connectors. The power being supplied to the board also changed; previously it was connected to a 3S LiPo battery. Now it's being supplied by a 12 V switching regulator, which is itself connected to a 4S LiPo battery. That supply can provide 3 amps and is fused. This may have something to do with it; I have not observed a failure when powered from a bench supply, the failure only seem to occur when connected to the switching supply. Due to the randomness, this could be just coincidence.

 

By the way, I've used the Wire-AND functionality on other boards and it works really well. I've found the added variety of pin configurations of the XMegas to be a really nice feature that helps keep part numbers down.

 

Avrcandies - I will take another look under a scope and see if I can spot anything. The board does experience some vibration and potentially mechanical stress in-use. That said, they were professionally built by a board house that usually does excellent work. The placement and choice of caps was made to reduce the risk of the caps shorting due to mechanical damage.

 

 

gchampan - I admit I did not consider ERP as a potential issue. As far as power planes go, the XBee and XMega are on opposite ends of the board. The 3V3 plane is actually cut into a U shape. The bottom of the U is the 3V3 regulator and then one end is connected to the XBee and the other leg is connected to the XMega. The ground plane is pretty much uniform. I can definitely do a better job of isolating the XBee and XMega, though. I'm going to run off a new batch of boards middle of the week, so now is the time to make changes.

 

First thing tomorrow morning, I'll try to break out the system clock and co-plot that with the power rail. I'm not sure I follow what you're saying about monitoring the ground plane. As far as cap placement, I can bring them back around to the top side on the next round of boards, just in case (I'm under the gun a bit here and am throwing darts...)

 

 

Thanks again everyone - even if we don't hit the nail on the head, you've given me some good information that I'll take with me to future projects.

 

Last Edited: Mon. Nov 6, 2017 - 03:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Post your port configuration code

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TMS8C8 wrote:
I'm not sure I follow what you're saying about monitoring the ground plane.
A very approximate way to measure the current between the probe's tips even when a near short.

Usually that method is not available with most 4-layer PCB (ground plane is buried)

TMS8C8 wrote:
As far as cap placement, I can bring them back around to the top side on the next round of boards, just in case
If the issue is XMEGA VCC then simply tack the capacitors you want to try direct to all VCC and GND pairs on the current PCBA (solder directly onto a QFP's pins)

TMS8C8 wrote:
(I'm under the gun a bit here and am throwing darts...)
May you aim and fire well and be fortunate.

 


High Frequency Measurements Web Page
Douglas C. Smith

Technical Tidbit - July 2007
Mobile Phone Induced Circuit Failure

http://emcesd.com/tt2007/tt070407.htm

...

 

Abstract: Cases of circuit failures caused by mobile, or cell, phones are starting to be reported. A brief overview of the problem is given followed by a simple test procedure to gauge the risk to a product.

 

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I'm definitely seeing 900 MHz noise on the clock and Vcc pins when the XBee is transmitting. If the noise is actually present on the clock and not just pickup from the probe, then I'm seeing the clock bounce up to 4.53 V and down to -1.23 V. 

 

Screen shot from scope (300 MHz, not 500 MHz as I said earlier) and screen shot of solder job is attached. The system clock (32 MHz) is being routed out through PD7. PD7 was originally routed to a USB connector. The trace is about 2" long and is sandwhiched between a ground and power plane, not in close proximity to the XBee, but that is relative. The board is only about 3" by 4". The other end of the trace is connected to a ESD protection diode and USB connector. There was no way to cut this trace due to the layout of the board, so it's likely not helping matters. I was able to tack in a 2k 0603 resistor right where PD7 drops to the inner layer. The other end is connected to a 50 ohm coax back to the scope. Shield is precariously tacked to the GND pin right next to PD7. 

 

:Edit: It looks like the large noise I was seeing on the clock signal is being picked up by the probe / long trace to the USB connector. If I configure that pin to be a high impedance input or input with pull-up, I still see the 900 MHz noise on it.

Attachment(s): 

Last Edited: Mon. Nov 6, 2017 - 08:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojo-chan wrote:

Post your port configuration code

 

Here is a snipped of configuration code for both PORTA (the XBee reset that failed on one board) and the XBee UART (failed on another board). The code is the same across all boards and - in some cases - run for weeks continuously with no problems. The likelihood of a code-related problem is very small but I wrote the code, so it's definitely possible! 

 

(The formatting seems a little funny when I paste into the code editor here... normally things are tabbed nicely

 

//PORT A 
#define PORTA_DIRECTION 0b11111100
#define RS232_READY		0
#define XBEE_CTS		1
#define XBEE_RTS		2
#define XBEE_SLEEPRQ	3
#define XBEE_RST		4
#define UART_RST		5
#define STATUS1_LED		6													//GREEN LED
#define RS232_OFF		7

//PORT C
#define PORTC_DIRECTION 0b10111000
#define SDA				0
#define SCL				1
#define RX0				2
#define TX0				3
#define LEDBANK1		4
#define STATUS3_LED		5													//RED LED
#define RX1				6
#define TX1				7

void board_init(void)
{
	
	PORTA_DIR = PORTA_DIRECTION;	
	PORTC_DIR = PORTC_DIRECTION;
	PORTD_DIR = PORTD_DIRECTION;
	PORTE_DIR = PORTE_DIRECTION;
	PORTF_DIR = PORTF_DIRECTION;	
	PORTR_DIR |= 0b00000011;
	
	//WIRED AND w/ PULL UPS for CS and RESETS:
	//PORTA_PIN4CTRL = (PORT_OPC_WIREDANDPULL_gc); //Failed and was replaced by totem pole drive
	PORTA_PIN5CTRL = (PORT_OPC_WIREDANDPULL_gc);
    PORTA_PIN7CTRL = (PORT_OPC_WIREDANDPULL_gc);
    PORTD_PIN4CTRL = (PORT_OPC_WIREDANDPULL_gc);
	PORTE_PIN4CTRL = (PORT_OPC_WIREDANDPULL_gc);
	
	//TOTEM POLE for XBEE RESET:
	PORTA_PIN4CTRL = (PORT_OPC_TOTEM_gc);
	
	//snipped code
}

void serial_init(void)
{
	//NOTE: All serial ports configured for 115200 BAUD rate
	
	//XBEE on PORT C
	USARTC1_BAUDCTRLA = 23;													// 0b00010111 -> BSEL 1047
	USARTC1_BAUDCTRLB = 164;												// 0b10100100 -> BSEL 1047 & BSCALE -6
	USARTC1_CTRLC = USART_CHSIZE_8BIT_gc;									//Configured for 8 data bits, one stop bit, no parity and async mode
	USARTC1_CTRLB = USART_TXEN_bm | USART_RXEN_bm;							//Enable RX and TX
	USARTC1_CTRLA |= 0b00010000;											//Allow receive complete interrupt at low priority level
	
    //snipped code
	
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TMS8C8 wrote:
:Edit: It looks like the large noise I was seeing on the clock signal is being picked up by the probe / long trace to the USB connector.
Can be confirmed by connecting the probe tip to probe ground; if the XBee carrier is present then the probe is defective.

An example of a well shielded probe that also has a 50ohm source termination (iow at the probe)

DC to 1 gigahertz probe, finished, BNC female to handmade probe tip

from http://emcesd.com/1ghz-6.htm and http://emcesd.com/1ghzprob.htm

with a pitch that would be close to that of :

CLKper, PC7 GND, 23 24

CLKper, PD7 GND, 33 34

CLKper, PE7 GND, 43 44

if able to try a different pin pair.

Should be able to lift a CLKper QFP pin from its pad.

 

P.S.

TMS8C8 wrote:
The trace is about 2" long and is sandwhiched between a ground and power plane, ...
Signals should be on the outer layers even USB.

Easier to probe and patch.

Outer layer signals are usually close enough to a low impedance plane.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the 3 pin chip on the left saying Vout...with no filter caps??!!!

 

Take a blank board and ohm out all of your gnd pads & supply pads to ensure they actually have a connection.  Do not use a populated board.  A missing connection like this can be masked by a false path through a chip, causing massive strangeness.

 

Please post a usable schematic.

 

If you are connecting this board to a PC or other gear beware of ground loops, the switcher output may or may not be floating, also a gnd loop concern.  I bring this up since it worked "fine" on batteries.

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can be confirmed by connecting the probe tip to probe ground; if the XBee carrier is present then the probe is defective

if it is a scope probe with the gnd clip lead, then this is sadly par for the course...the scope probe is not defective, but simply not useable in this situation (need something like the hand-built one shown). The long gnd clip lead forms a nice antenna & its inductance /ringing affects the captured waveshape.  Sometimes scope probe come with a solderable mount for "direct" pcb connection without the noise picking gnd lead. 

When in the dark remember-the future looks brighter than ever.

Last Edited: Mon. Nov 6, 2017 - 11:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
Sometimes scope probe come with a solderable mount for "direct" pcb connection without the noise picking gnd lead.
A BNC-to-probe adapter can be patched onto the PCB surface.

http://www.shop.ezprobe.com/TEX-BA-BNC-to-Probe-Tip-Adapter-TEX-BA.htm

http://probemaster.com/4952ba-bnc-adapter/

http://probemaster.com/4987ba-bnc-adapter/

 

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

here is one goes direct--- plug your scope probe right "into" the PCB

 

http://www.alltest.co.il/products/oscilloscopes/n2766a-horizonal-mini-probe-socket-qty-25.html

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

What is the 3 pin chip on the left saying Vout...with no filter caps??!!!

 

Take a blank board and ohm out all of your gnd pads & supply pads to ensure they actually have a connection.  Do not use a populated board.  A missing connection like this can be masked by a false path through a chip, causing massive strangeness.

 

Please post a usable schematic.

 

If you are connecting this board to a PC or other gear beware of ground loops, the switcher output may or may not be floating, also a gnd loop concern.  I bring this up since it worked "fine" on batteries.

 

I'll try to get a more readable version later today. That chip is a temperature sensor: MCP9700T-E/TO. There is a bypass cap on the temp sensor supply and nothing on the output, as per datasheet. 

 

I will also double check the boards. They bare boards were electrically tested before assembly according to my netlist but there's always a chance I goofed up the netlist when drawing the schematic.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

Can be confirmed by connecting the probe tip to probe ground; if the XBee carrier is present then the probe is defective.

An example of a well shielded probe that also has a 50ohm source termination (iow at the probe)

 

Should be able to lift a CLKper QFP pin from its pad.

 

Signals should be on the outer layers even USB.

Easier to probe and patch.

Outer layer signals are usually close enough to a low impedance plane.

 

 

Couple of things:

 

The "probe" I'm referring to is just the coax soldered to the board. I realize now that the image is misleading. The witch's hat probe is looking at Vcc, not the clock signal. The system clock is being measured by the coax that is tacked to the board in the lower right hand corner. You can barely see it in the photo, but there is a very fine (2 strands) copper wire going from the shield/drain on the coax to the GND pin right next to PD7. PD7 is soldered to the resistor (almost impossible to see), which is then soldered to the center conductor on the coax. The center conductor of the coax has a larger diameter than the length of the 0603 resistor. I was using the internal 50 ohm terminator on the scope, not terminated at the source. I thought this would be sufficient but I think the long "dangling" trace is hurting me here.

 

The ATXMega in this design is a QFN part. Soldering the ground on the coax was actually the most difficult part because that pin was routed to the center pad under the chip (where there are a bunch of vias down to the ground plane) so not only did I have almost no room to solder anything, but it was hard to get enough heat into the joint to solder without risking damage to the chip. Originally, the design was going to be on a much smaller board, so the smaller package was chosen. I now have more room but didn't think to up the package size... I should have. It would make trouble shooting easier.

 

I will add "keep signals on the outer layers" to me list of best-practices but sometimes it's just not possible. I recently completed a very compact, 10 layer DAQ and processing board. 2 FPGAs, ARM processor and high speed DAQ all on a board about 3" by 3". Luckily, that one works! 

 

Hope it doesn't read like I'm refuting any of the good advice given - just trying to give feedback and bounce ideas off of you guys to learn.

 

Last Edited: Tue. Nov 7, 2017 - 11:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No problem ... well ... other than your "headache" wink

TMS8C8 wrote:
The center conductor of the coax has a larger diameter than the length of the 0603 resistor.
For such, through-hole resistors are easier to work with.

TMS8C8 wrote:
... but I think the long "dangling" trace is hurting me here.
... or that VCC probe.

TMS8C8 wrote:
The ATXMega in this design is a QFN part.
Thanks

Thought so at first but then over-ruled myself (I of four eyes who is half blind)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As promised, attached is the PDF version of the schematic. It should be readable and with components values instead of ref des.

Attachment(s):