Fail to read Device Signature, unable to enter programming mode

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

Thanks in advance if anyone has an idea of what's going on.

 

I have an ATxmega256A3 and I'm unable to read the device signature. All connections should be correct, reads correct target voltage. I don't believe the fuses should be incorrect, but I guess it could be a possibility by mistake. I've been using AVRISP mkII to program with atmel studio 6.1.

 

Any suggestions on how to fix this situation?

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

How 'bout if you try it again right away. Seems to be some bug, but mine ALWAYS fails the first time after connecting my Atmel-ICE to the computer. Works from then on as long as I have the connection right-way-around.

274,207,281-1 The largest known Mersenne Prime

Measure twice, cry, go back to the hardware store

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

Thanks for the advice Torby, unfortunately it does keep failing after the first time still. I was having issues before where it would fail to enter programming mode every three times I would try to read device signature. I tried to program the xmega while this was occuring which did seem to work but after this I could no longer read the device signature. I confirmed the flash was programmed with the application.

 

Maybe this info will help clarify some things.
 

EDIT: May also help, when everything is connected before I try to read device signature I have the green LED lit. After I try to read, flashing red.

Last Edited: Thu. Sep 11, 2014 - 07:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 3

Is this your own designed PCB, or a commercial PCB?

 

Are there any caps or resistors on the reset line?

There shouldn't be.  The two PDI lines are suppose to have matched impedances.

If the board will operate in a "noisy" environment, and a cap is desired on the reset line, then it should be added after the programming. 

This could be by a header/jumper, solder bead across two pads, etc.

 

Does the uC have by-pass caps across EVERY Vcc/Ground and AVcc/Ground pair of pins?

Are ALL Vcc and AVcc tied to V+; and are ALL of the Ground pins, and AGnd, tied to Ground?

Is AVcc tied to Vcc, either directly, or through an LC filter?

 

I recall one or two Threads where people stated that the ribbon cable connector on the AVR ISP mkII's programming cable was loose/worn at the connector inside the plastic case.

They replaced the cable, (or recrimped it, whatever), and it worked fine once again.

 

Also, I just saw in another Thread a suggestion to upgrade Studio 6.1 to 6.2.

I am not familiar with the changes to Studio in that upgrade, so I don't know if it involves the PDI interface or not.

 

If there is an upgrade option for the mkII then you should do that, also.

 

Do you have any other PCB's, Xmega or otherwise, to validate that the mkII is working properly / reliably?

 

Do you have a second copy of the current, problematic PCB to test?

 

Does your PCB have a very clean power supply, at what voltage, and what is the Brown Out Detector set at, (if you can read the Fuses again)?

 

There have been prior reports of PDI programming problems with the Dragon, but the mkII usually works great.

 

JC

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

Commercial PCB.

 

I can go through the pcb schematic and verify all the caps, resistors, Vcc, GND but these should all be correct. Issue occured on another setup with atxmega256a3u, also tried another mkII with the atxmega256a3u which failed(never had an issue with this board before). Reinstalled atmel studio 6 didnt change anything. I will attempt to update 6.2 but recall I was unable to a while ago.

 

I do not have another copy of the problematic PCB, I've been trying to obtain one but still haven't been able to.

 

Can't read the fuses at all(fails to enter programming mode) so unsure of Brownout Detector. The power supply I've used for a couple months now with no issue on many boards.

 

I very much appreciate the help. Is there anything I could've possibly done strictly through Atmel Studio that would've caused me to not be able to program the device again?

 

 

Last Edited: Thu. Sep 11, 2014 - 08:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The only way I know for sure to "brick" an Xmega is to set the Brown Out Detector to a higher voltage than the supply voltage.

 

Note that there is quite a wide +/- range surrounding the BOD voltages stated in the data sheet and on the Studio dialog.

The actual allowance is shown in the back of the data sheets.

 

If this is done then the BOD will hold the Xmega in reset, and it won't run, or program.

 

If this is the problem it is easily fixable.

Power up the PCB with a variable power supply, and a DMM on the supply rail, and very, very carefully crank up the voltage.

Vmax is typically 4.0 V for the Xmegas, but check the data sheet for the specific Xmega you are using, (Electrical Characteristics, Absolute Maximum Ratings, near the end of the data sheet).

 

Don't exceed Vmax, but if you have Vsupply a bit over the BOD voltage, AND RESET the chip, it will work again.

Then reset or disable the BOD.

 

I recall some discussions about the JTAG interface, but I am not a JTAG user so I don't have any experience with that.

It was my impression that the PDI interface was suppose to work regardless of whether or not the JTAG interface was enabled via its fuse.

 

Perhaps someone else with more experience in this can comment on whether or not the JTAG fuse setting can disable the PDI interface.

 

I do not know of any other way to brick an Xmega.

The classic way to brick a Mega or Tiny by setting the clock source to a non-existent clock source doesn't apply to Xmegas, as they always Boot up on their internal clock.

 

If the PCB has never been able to be reliably communicated with for Signature and programming, then I would certainly expect it to be a problem with the PCB, not with the mkII.

 

JC 

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

Thats good to know that its pretty difficult to brick an XMega, I'm rather new working with AVR devices and just started working with them this past week.

 

From what you've posted the BOD isn't incorrectly set as the board does run what is currently programmed on the flash. Still doesn't tell me where the issue is causing inability to reprogram, but I'm less worried knowing it should be fixable.

 

I'll follow up with all the suggestions made and let you know what additional information I find out, but I have a feeling it may be an issue with the mkII as it wasn't able to communicate with a second setup that I haven't had an issue with. Hopefully its nothing to difficult to correct.

 

Thanks a ton.

 

Brandon

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

I had to go into the tool properties / PDI Speed?? (dont have it infront of me) and pull the speed up quite high (4-5Mhz) and since then it connects every time. But the clock on the chip was already at 32Mhz by that point.. so i'm not sure of the result if the chip is still at 2Mhz Default. 

Jacob

Dreamin' EE

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

All Xmega's power up at 2 MHz.  They won't change to 32 MHz until they are running your program, and your program reconfigures the clock.

If the mkII connected to program the Xmega, that connection was with a clock of 2 MHz on the Xmega.

 

Good to hear you have it working.

 

JC

 

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

I guess I wasn't too clear. But I did test it on another xmega chip that has never been programmed. If I leave the pdi clock at the default setting, getting device information is like pulling teeth. But even without flashing any code into the xmega (I have dozens of them so I tested a few) if I pulled the pdi clock up to 2.5Mhz+ it connected every single time without fail. Which coming from the atmega works seems weird that it doesn't need to be lower than the current system clock. But... It worked for me over and over. Using the atmel-ice. Maybe this isn't new news, but when I was originally trying to get all that working, I couldn't find to much useful info online. (I actually just ended up thinking that I had a few bad xmegas since they all were revision E, the problem filled revision).

Jacob

Dreamin' EE

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

Interesting...

274,207,281-1 The largest known Mersenne Prime

Measure twice, cry, go back to the hardware store

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

hi, if  you don't mind, where is the setting for pdi speed?  my atmel avrisp mkii and olimex avrisp mkii show no interface settings available, and the Tool info has nothing about pdi speed.

 

I keep my wire length short to 150mm.  the Olimex avrisp mkii will pdi xmega128a4u's (all) whereas the atmel avrisp mkii pretty well will not pdi any.  Olimex is half the price.  they have a terrible target voltage circuit (100 ohm pull-down), so you CAN NOT connect the target voltage or all your target supply power is sucked out.

<p>Vern</p>

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

DocJC,

 

Thank you.  Cap and resistor on the reset line were stopping communication.

 

Very happy to find your post,

 

DrewG36

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

Welcome to the Forum!

 

Glad you solved your problem.

 

JC

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

Thank you very much, DocJC. 

 

Good to know that capacitor and resistor on the reset line that can be a problem. After reading your post and removing capacitor and resistor, my design is working well.

 

Wish you all the best!

 

Thanks 

Tony

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

Hi Tony,

 

Welcome to the Forum.

 

Glad to hear you have your board up and running.

 

JC

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

 

If caps and resistors cannot be present on PDI_Data and PDI_Clock, can these pins be used for any other purpose after programming ? Can a switch be added to the reset line with a pull up to force the avr to reset ?

 

I currently have a 10k pullup on RESET with a switch to ground and not entering program mode.

 

SB

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

It is common to have a push button switch connected to the reset pin, so you can reset the device by grounding the pin.

 

The other PDI connection goes to the PDI pin on the chip.  I think it has no other purpose. It's just there for PDI. 

 

Just be glad you have PDI.  I was looking at another thread with JTAG trouble.  I think the JTAG had 6 or 8 freakin' connections.

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

stevenbulmer wrote:

I currently have a 10k pullup on RESET with a switch to ground and not entering program mode.

 

SB

If you mean invoking a bootloader via a push button, that requires another push button.  You'll need to know what pin the bootloader checks.

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

stevenbulmer wrote:

 

I currently have a 10k pullup on RESET with a switch to ground and not entering program mode.

 

 

That might be too much of a load for the reset line. Try removing the resistor or maybe you could try using 68k. I don't use any pullup on the xmega reset line.

 

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

The Reset\ / Clock and the Data pins for PDI are just for Reset\ and programming.

They do not serve as general purpose I/O pins.

 

The above post mentions a small cap, when used with the Dragon programmer, as a "solution" to the Dragon's failure to successfully perform PDI programming on some Xmegas.

 

The original Xmega literature said do NOT connect any resistors or caps to the two PDI pins, and they are suppose to have matched impedances.

 

The serial resistors above are different from a pull-up resistor, do not confuse the two.

 

Have a pull-up resistor on one of the two PDI programming pins clearly gives the pins an unequal impedance, and would be expected to cause problems.

 

This is very different from the AVR Tiny and AVR Mega micros where one can, and often does, put a pull-up resistor on the Reset\ pin, and a small cap to ground, with a push button reset switch.

 

JC