6
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ I seem to recall you can turn the clock rate on the PDI programmer down, have you tried that? Unprogrammed AVRs use the internal oscillator by default fuse settings (1 or 2 MHz I believe) from the factory, and you're supposed to limit the programming frequency to a fraction of that. Also since you have a Dragon, why not try using the 6-pin ISP programming interface - its use is much more widespread. \$\endgroup\$
    – vicatcu
    May 22, 2012 at 16:39
  • \$\begingroup\$ The ATMega*D3 only supports PDI, no ISP, no JTAG. Also because the AVRDragon interface view in Atmel Studio doesn't have a speed option, I think that is because PDI provides it's own clock. I tested the AVRDragon with an ATMega16 board using ISP and it worked as expected, so I have seen the setting you are referring to. \$\endgroup\$
    – James
    May 22, 2012 at 17:10
  • \$\begingroup\$ I must just be mis-remembering- sorry \$\endgroup\$
    – vicatcu
    May 22, 2012 at 17:41
  • \$\begingroup\$ @James - Post your solution as an answer. You can accept it in a few days. You won't get rep for it, but others will see immediately that the question is answered. \$\endgroup\$
    – stevenvh
    Jun 1, 2012 at 5:45

6 Answers 6

Reset to default
4
\$\begingroup\$

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).

\$\endgroup\$
3
\$\begingroup\$

No, a length difference of 10mm will not cause problems; it's worth a delay of about 50ps, or 0.05ns.

Unprogrammed microcontrollers are sometimes erased so that all of program memory reads 0xFF. What happens if you run this depends on your controller. Some controllers have 0xFF as machine code for a NOP, so that the controller doesn't do weird things if unexpectedly would see a block of unprogrammed or unexisting Flash. The program counter will run through it until it reaches 0xFFFF, wrap around to 0x0000 to arrive at the reset vector. This depends on your controller. If it's erased you won't see anything happen. If 0xFF would be the code for another instruction anything may happen, but it would be very lucky to see activity on I/O pins.

They also may contain a test program used in production. You can disassemble it if you really want to know what it does, my guess is that it will execute an algorithm involving as many as possible different instructions and activate some output when the algorithm is executed correctly (other I/O will also be used in the process).

Also possible that it hasn't been erased and that it contains garbage. I've never had controllers like that.

\$\endgroup\$
12
  • \$\begingroup\$ Some controllers are factory-programmed with a boot-loader (very nice). Others, when blank, will execute sequential code until they "fall of the end", but will then do undesirable things after that happens (e.g. try to use a bunch of I/O pins as a memory bus). I remember one 68HC05-based device I had to work on which would thrash its I/O wildly if it fell off the end of code space and also cause an instant reboot of a Windows 3.1 PC (386sx-based) that was plugged into its UART. That was annoying. The "watchdog" chip was connected to one of the wildly-thrashing I/O's, so it was happy. \$\endgroup\$
    – supercat
    May 22, 2012 at 15:44
  • \$\begingroup\$ @supercat - a boot-loader, wouldn't that be in ROM rather than Flash? (Guessing, I don't know.) \$\endgroup\$
    – stevenvh
    May 22, 2012 at 16:02
  • 1
    \$\begingroup\$ @stevenvh, that distinction gets messy, when the ROM is made using Flash memory people often start using Flash to mean ROM and there is still extra flash for runtime use by the chip. I know many that say flash instead of ROM much to the chagrin of more experienced guys. I guess live and let live on that one. \$\endgroup\$
    – Kortuk
    May 22, 2012 at 16:17
  • \$\begingroup\$ @Kortuk - I don't mind if they implement it as Flash, when I say ROM I mean not erasable. In general are those boot-loaders protected? \$\endgroup\$
    – stevenvh
    May 22, 2012 at 16:20
  • 1
    \$\begingroup\$ @stevenvh I take your point... at any rate the PDI interface on AVRs is a hardware programming interface with no dependency on a bootloader anyway \$\endgroup\$
    – vicatcu
    May 22, 2012 at 16:38
2
\$\begingroup\$

The general question of "What is the behavior of an unprogrammed MicroController?"

Answer 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.

My specific situation was resolved by using the AVR JTAG ICE 3 programmer, the MicroController was detected and it read the signature and fuses perfectly. While the AVR Dragon may technically support PDI, it may need additional pull-up/pull-down resistors or have other circuit requirements to work as expected.

There are many great suggestions here, so read them all if you are experiencing the same problem.

Also note: http://www.atmel.no/webdoc/atmelstudio/supported.devices.notes.1.html Up to Revision K of the A3/D3 Xmega's are not supported by AVR Dragon. (8-17-2012)

\$\endgroup\$
1
\$\begingroup\$

Official Atmel website says:

XMEGA PDI issues: XMEGA PDI mode on AVR Dragon does NOT work for the following XMEGA devices: A3/D3 - revisions B, C and E or A1 (up to revision K)

http://www.atmel.com/webdoc/avrdragon/avrdragon.known_issues.html

\$\endgroup\$
0
\$\begingroup\$

From AVR App Note 1005:

5.1 Hardware design requirements to make PDI work

The PDI interface is a synchronous half-duplex UART interface. The two lines, PDI_DATA and PDI_CLK, must therefore be balanced. If you place a strong pull-up and decoupling cap on the PDI_CLK, which is also the Reset line, the clock and data will no longer be synchronized correctly. Therefore, during development you should remove any pull-up and decoupling capacitors. This also applies if using the PDI interface for in-system programming the XMEGA in production.

Also have you wired the device to the programming header per this picture?

enter image description here

\$\endgroup\$
3
  • \$\begingroup\$ This is the document/footprint, I based mine from and I've reviewed it several times already, but for the moment I'm not 100% on the PDI pins, so I will check it again. Thanks. \$\endgroup\$
    – James
    May 22, 2012 at 18:24
  • \$\begingroup\$ might help if you posted the relevant aspects of the schematics and layout \$\endgroup\$
    – vicatcu
    May 22, 2012 at 19:25
  • \$\begingroup\$ I did verify this Connector and it's correct. It's hard to isolate this part of my schematic and layout, also I wanted to try and make this question a little more generic so it could help more people than just me. \$\endgroup\$
    – James
    May 23, 2012 at 14:24
0
\$\begingroup\$

The pdi interface puts the microcontroller in reset, so unprogrammed or programmed, once you yank reset it doesnt matter. If you had the part in backwards you could have fried it or other things including your programmer, so everything is suspect at this point.

the pdi protocol, at least on the xmega (atmel may have two different ones both called pdi) I programmed, definitely has timing restrictions on the clock, your wire/trace lengths are likely not a problem. But if you pause too long on a clock cycle the part automatically goes out of programming mode and you have to start all over. there is a init sequence that has to happen. for example if you read a memory/flash location then stop to print it out, then go back, you may have taken to long and have to re-init. it is not hard at all to bit bang xmega pdi, have you tried that instead of using some other programmer that tries to be a one size fits all (which never fits anyone well)?

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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