XMEGA freezes on PDI / NVM access

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

I have an issue with ATXMEGA64A1 (the one with a long errata list).

 

On a batch of ten PCBs, about half of them exhibits the following behavior:

 

Everything is working fine after the first programming, but when the ISP dongle (Atmel ICE) is disconnected and reconnected, execution stops and the PDI interface stops working. Target voltage can correctly be read to 3.3 V, but device signature can not be read. Needless to say, none of the other controls in the Atmel studio device programming dialog are available.

 

("PDI enable failed. Debugger command Activate physical failed.

Unable to enter programming mode. Verify device selection, interface settings, target power, security bit, and connections to the target device.")

 

This behavior can also be trigged by SW when I erase the upper half of application section, which is not used by application code.

This makes be think that the problem is not the PDI itself, but the NVM controller.

 

The MCU stays in this state after power cycle, so it seems more or less bricked. The only way to make it exit the state is by using some cooling spray on the MCU (or unplug it and wait a long time, but I guess it is related to cooling down as well). When using cooling spray (with power applied), the execution will resume within a few seconds, and I can now read signature, set fuses, write new binary etc. I have to be fast though, because when the MCU heats up PDI will become unavailable again. However, execution will continue until the dongle is unplugged and replugged.

 

And when I say warm up, I mean slightly above room temperature, approx 30-35 degrees C.

 

Note that the same code works fine on about 50% of the boards.

 

The ISP connector is located about 4 cm from the MCU, and there is nothing on the data and clock lines except for a 20 k pull up on reset.

Running the PC on battery makes no difference, so no ground loop as far as I know.

This topic has a solution.

Last Edited: Fri. Jul 1, 2022 - 07:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dimlite wrote:

This makes be think that the problem is not the PDI itself, but the NVM controller.

...

Running the PC on battery makes no difference, so no ground loop as far as I know.

Try the XMEGA64A1 on a cell or battery as NVM controls an internal charge pump.

Reason : XMEGA can upset voltage regulators

XMega SRAM slow turnaround? - Solved (Glitchy Power Supply). | AVR Freaks

 

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

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

And when I say warm up, I mean slightly above room temperature, approx 30-35 degrees C.

 

? ? ?

 

Something (obviously) is wrong with the board / design / assembly.

I don't believe that the Xmega should be getting that warm.

 

Can you post a schematic diagram of the circuit?

 

Can you post a photo of the PCB?

 

Did you hand assemble the boards, or are they professionally assembled?

 

Are ALL of the Xmega's Vcc and AVcc pins connected to power?

Are ALL of the Ground pins connected to Ground?

Do each pair of power pins have a 0.1 uF by-pass cap mounted close to the micro?

 

When you used a battery, was that still feeding a voltage regulator, or did you supply 3V directly to the PCB & micro?

 

If you were still using a voltage regulator on the board, then re-check, very carefully, the data sheet for the voltage regulator, and the type and value of the output capacitor, (and it's ESR value).

Some 3 V regulators are very picky about their output capacitors or they can oscillate, and then Vout can exceed 3V, and then the Xmega can get very hot or destroy itself.

 

JC

 

Last Edited: Thu. Jun 30, 2022 - 03:42 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Thanks for your support, but we found the solution now, and it turned out to be quite obvious.

 

The interpretation of the BOD level bits has changed from ATXMEGA64A1 to ATXMEGA64A1U. I was reusing some code from an XMEGA192A1U. In the datasheet for A1U, a BOD level of 0b001 equals 2.8 V, whereas in A1 the same value means 3.2 V. So with VCC = 3.3 V, I was close to BO all the time, and when doing something that required a little more power, like writing to flash, BOD was triggered.

Last Edited: Fri. Jul 1, 2022 - 07:18 AM