Electronic – the behavior of an unprogrammed MicroController

atmelavrmicrocontrollerpcb-designxmega

Problem:
I get Errors when trying to connect to the MicroController using the PDI interface. How does a MicroController behave when it hasn't been programmed? Is there a pin that will toggle to show me it's OK? Kind of a hardware "Hello World"?

I would like a way to confirm if the MicroController has failed or if I've done something else wrong.

Additional Information:

I've designed and had manufactured a custom board for an Atmel XMEGA MicroController, ATXMega64D3 to be exact. I'm using the ATXMega192D3 for prototyping, but these chips are identical except Flash/SRAM/EEPROM.

At this point the Power Supply is a verified and stable 3V3 Breadboard Power Supply to all power pins on the MicroController and the Power pins of the PDI connector. I have most of the decoupling Caps recommended in AVR1012: XMEGA A Schematic Checklist, section 2.1. I placed jumpers instead of the inductors & beads specified, and have not installed the electrolytic capacitors.

Total Parts installed = 6 qty 100nF decoupling Caps, 1 MicroController, 6-Pin header for PDI.

The MicroController is a 64-pin TQFP which I soldered on by hand under 7-14x Magnification. Then inspected for solder bridges.

I live in the Seattle area and it's been raining, I'm a native so I haven't turned the heater on. Odds of static damage are very low.

Programmer is an AVR Dragon, using the latest (non-beta) of Atmel Studio 6.0. Which reads the boards power level correctly but can't actually communicate with the MicroController.

My Current Theory:

I checked my design and the PDI Clock trace is 15mm long and the PDI Data trace is 25mm long, is this enough of a difference to cause Sync Issues? I would like a way to confirm this before going through the time and money of having a new board made.

Thank you for any help or ideas.

Update
Still not working, but I have found and fixed the following issues.

  • The MicroController was installed 180 degrees from what is required. The uC that I have has 2 circles in diagonal corners. When I first installed it I oriented the larger circle to line up with my Sikscreen. Only later when I read the logo did I realize that when the Logo is oriented correctly the Pin #1 identifier (smaller circle) is in the upper left.
  • Because I had started with the Voltage Regulator on the board, my power supply was set to 5V which is beyond the maximum voltage for this chip. So I have replaced the MicroController with an extra that I purchased at the same time.

At this time my theory is the AVR Dragon is my issue. The documentation states that the Dragon can connect to XMega with PDI but I have found multiple comments that seem to show about a 30% success rate, depending on the XMega model.

As an FYI with Power applied, the non-power pins read between 50mV and 300mV. Once again this is an un-programmed uC so there isn't any code running. This could be a leakage voltage or it could be the default configuration of the pins I'm not sure.

Solution

Using the AVR JTAG ICE 3 programmer it showed up, read the signature and fuses perfectly.

Best Answer

My next step would be to install the electrolytic capacitors as recommended in the Schematic Checklist you mentioned. If it still doesn't work, I would go ahead and install all the inductors, etc. recommended in the checklist -- maybe there is a reason Atmel published that checklist :-).

If it still doesn't work, I would fall back on the sorts of errors I often make:

  • When I probe the VCC and AVCC power pins with a multimeter, does each and every one of them show I have the correct 3.3 V?
  • Is each and every one of the GND pins solidly connected to GND?
  • Did I maybe install the PDI connector backwards or upside down again ? Or maybe forget to connect one of its pins to the MCU? (Use a multimeter to beep out the connection, one probe directly on the MCU chip pin, the other at the far end of the cable to the part of the programmer that pin is supposed to be connected to)
  • Have I used the multimeter beeper to confirm that I haven't shorted any two adjacent pins?
  • Is there maybe something wrong with the Dragon programmer or the cable between it and the board? Does the Dragon program work right when I use it to program some other similar AVR chip, perhaps a through-hole chip crammed into a solderless breadboard?

Could you post a photo of your PCB?

With most digital electronics, even if the PCB is known to be incorrect, it's usually quicker and easier to cut traces and add jumper wires on the prototype until you at least get to the "blink an LED" stage than to wait for another PCB to be fabbed that has fewer problems with it.

10 mm extra trace length is irrelevant in this application. I'm almost certain that is not the problem.

After I've exhaustively made sure that everything is connected properly, as recommended by the manufacturer, and there's no shorts between adjacent traces, and the program still doesn't "recognize" the chip, only then would I conclude the chip is a dud and get a replacement chip.

Later, after you get the programmer to "recognize" the chip and start to program it, then you can think about:

Is there a pin that will toggle to show me it's OK? Kind of a hardware "Hello World"?

Yes. Blinking an LED is considered the equivalent of "Hello World" in electronics. a b c d This doesn't happen automatically, though -- you need to connect a pin to an LED and you need to write some code to blink it.

Even after a person programs the other pins to do useful things, they often leave the code in to blink a "heartbeat" LED a b that once a second or so. That makes it pretty much instant to confirm that the program is loaded and running, the right frequency of crystal is connected, etc. (Some people deliberately change the blink rate every time they reprogram the chip, just to reassure themselves that the chip is now running with the latest code rather than the old code).

Related Topic