Is it possible to lock yourself out of XMEGA by software?

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

I was thinking what would happen if a program for one MCU was programmed into another MCU via bootloader which doesn't check for device ID before bootloading.

I was thinking that it could cause physical damage such as setting input pins as output pins where they're in short circut wiring with VCC or GND.

I also thought what if it could write into the I/O registers to write lockbits or fusebits to disable the programming bit which would doom XMEGA to have to be unsoldered from its current board, soldered to a 12V MCU fixer (if one even exists and if it's not just for ATTinys), and then solder it back onto the previous board.

 

Is this really possible to do? Like, lock yourself out completely from XMEGA by software?

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

Fuse bits and lock bits do not prevent access to IO registers (or SRAM), as far as I know. Lock bits ONLY limit external access to flash.

 

Fuse bits can, for example, try to switch to an unconnected external clock oscillator but the XMega has an internal oscillator that it will always fall back to. The other "classic" excluder is RSTDBL fuse (disables external reset and uses that pin for GPIO). Once that is set, you cannot program it by conventional means any more but I don't know if XMega devices have that.

 

Jim

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

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

soldered to a 12V MCU fixer

That would doom the Xmega for sure.

There is no 12 V interface for the Xmegas. 

 

The Xmegas have the PDI interface, and a JTag interface on the larger ones.

As far as I recall, the PDI interface is always active, so one would never need to remove the chip from the PCB to re-program it.

Note that one might have to erase the entire chip, but one could then reprogram it.

 

IIRC the Fuses and Lock Bits are not software programmable.

 

The issue of either the "wrong program" or a software error setting a pin high or low which is tied to Vcc or Ground exists on any micro.

That is one reason, on some designs, one will see a small valued resistor in series with pins connected to external drivers, (or rails).

An error, then, will limit the current to a pin safe value.

 

JC

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

The Xmega Reset\ pin is p[art of the PDI interface, and can not be converted to an I/O pin, so disabling the Reset\ function isn't possible on Xmegas.

 

Know that it is possible to, using a programmer, set the BOD to a level above the Vcc, which will then lock the chip.

That is the only way I know of to lock / brick an Xmega, (User Error!).

 

That situation is correctable, however, by slowly raising the Vcc and hitting the Reset\ to bring the chip back to life, and then setting the BOD appropriately, or disabling it.

 

Note that that method could fail, however, if one had a low voltage device on the PCB that could not tolerate 3.3 V.

 

JC

 

 

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

Surely the whole point of Xmega starting at 2MHz on their internal clock every time (rather than relying on fuses to set the clock selection) is one of the "lessons learned" with Tiny/Mega was the debacle with CKSEL  that left so many people with "fuse accidents". The other "dangerous" fuse in tiny/mega was RSTDISBL on the small ones (28 pins or less) that freed a valuable IO. The xmega doesn't have an equivalent. So they are "safe" aren't they?

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

Which brings up the point: why would any sane person connect an IO pin to either Vcc or Ground. I cannot think of any reason to do so and many reasons NOT to.

 

Jim

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

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

I locked myself out of a Xmega when I did some changes to the hardware but programmed the wrong code into the chip which was using the pins incorrectly. blush

 

Fortunately it was a prototype and a sharp scalpel "fixed it" enough to put the right code into the chip and re-soldered the track.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Which brings up the point: why would any sane person connect an IO pin to either Vcc or Ground. I cannot think of any reason to do so and many reasons NOT to.

 

Well, one might put a small DIP switch to program in a setup code, module ID code, etc.  But then a small series resistor would be helpful.

 

JC

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

ka7ehk wrote:

Which brings up the point: why would any sane person connect an IO pin to either Vcc or Ground. I cannot think of any reason to do so and many reasons NOT to.

 

A couple of obvious reasons spring to mind. It can be useful when doing board revisions to signal which revision the MCU is on by wiring some pins to GND. On start up the MCU enables pull ups and checks if those pins have risen, and if not knows it is on a revision 4 board and acts appropriately.

 

The other one with XMEGA is the differential ADC. The mux has two GND inputs, what it calls internal GND and pin GND, but in practice both end to be a little different to GND measured on an I/O pin. For precision measurements, you often end up connecting an ADC input to GND.

 

I've done both those things in commercial designs, and it works fine. Both idle at low single digit microampres, there is no leakage.

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

Aren't push buttons connected to VCC and an IO pin?

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

Usually you connect push buttons to ground and an io pin.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

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

Torby wrote:

Usually you connect push buttons to ground and an io pin.

How do you read the button state then? On the final project presentation, I connected a button to the IO pin through the VCC and read 0 for not pressed and 1 for pressed. But if I had made the IO pin an output pin, I think that would cause a short circuit. By putting a resistor before the IO pin, doesn't the voltage drop below the zone of "1" detection?

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

Is it possible y'all are losing sight of Jim's original point? I think he was implying that no one would make a DIRECT connection from an I/O pin to Vcc/Gnd.

 

But of course buttons may well have a SWITCHED connection to one or the other.

 

As to whether it happens to be Vcc or Gnd that surely depends on which way your non-connected pull-up/pull-down happens to be situated. Obviously mega/tiny encourage the use of pull-up and active connection to Gnd simply because the chips provide pull-ups but not pull-downs. But if both were available I expect the common choice would be pull-down with a switched connection to Vcc simply because it makes the pin read the more obvious '1' value when active.