AVR CPU exceptions?

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

This is something I'm curious about...

Since the AVR architecture does not have privilege levels and CPU exceptions, what happens if you try to perform some kind of illegal operation (access a nonexistent physical memory address, execute an illegal instruction, etc)? Does the chip reset, crash, or just continue on its way?

Does the AVR even have illegal instructions? I looked at an opcode list and it seemed from a quick glance that nearly all bit combinations are used, and some opcodes are even duplicated...

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

Quote:

nonexistent physical memory address,

Generally the address bus "wraps" and you end up with something. If you were using ext-ram and addressed a non-existent device the chances are you'd still get a wrap effect if only the lower address lines are connected.
Quote:

execute an illegal instruction

It seems to just act as a NOP. 0xFFFF is undefined , for example, but as this is typically what's in unprogrammed flash if you run into some it just churns through until it hits something looking like real code - probably after the address wrap back to 0x0000.

So it's pretty robust to "going rogue" - on the whole it'll tend to end up in what looks like a "reset" anyway.

Cliff

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

Quote:
So it's pretty robust to "going rogue" - on the whole it'll tend to end up in what looks like a "reset" anyway.

Not that you should rely upon it. The behaviour is oficially undefined, and the mcu is free to do whatever it likes - including fryig itself. Or at least you should treat it so.

JW

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

Cliff is right about the wrap around. For example, on reset the stack pointer is set to zero and it points to R0.Two pushes will write to 0xFFFF (the wrap around value) and if you don't have SRAM, it is an undefined position. RCALL or RET will crash the system in this case.But yeah, there is no warning like an unhandled exception or anything like that.

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

I wonder if a processor with an illegal opcode trap is 'safer' than one without it? If the terrorist EMP bomb goes off near both types of processor and scrambles the ram, who resets and resumes operation the fastest? Might be a consideration for something like a flight control computer that might get hit by lightning, or some other safety critical situation.

Imagecraft compiler user

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

npat_avr wrote:
For example, on reset the stack pointer is set to zero and it points to R0.
Although that is true of some devices (mostly older ones, I think) some devices set the SP to a non-zero value on reset. For example, the mega644P sets SP to 0x10ff at reset while the mega1280 sets it to 0x21ff. As always, consult the datasheet for the device you're using.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

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

not to hijack the thread, but does that mean the SRAM begins from 0x10ff?

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

Was it once advised to set all unused areas of the EPROM to the RST opcode? So long ago now.

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

npat_avr wrote:
does that mean the SRAM begins from 0x10ff?
If you're referring to the initial SP value for the mega644P, that is the last byte of RAM. A push instruction writes the register to the address contained in the SP and then decrements the SP.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

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

I know the data sheets don't say anything about it, but AVRs (and many other types of uCs) have a LOT of write only memory

"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
-- Douglas Adams

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

I think exceptions were invented to better support multitasking operating systems and as such to protect the tasks from each other. One rogue process does not bring down the whole system.

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

Also any unused flash location will have 0xFFFF which when decoded by the ALU, is like a NOP, does nothing but moves to the next instruction. So if you accidently jump to any of these locations, the system will crash.

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

Quote:
Might be a consideration for something like a flight control computer that might get hit by lightning, or some other safety critical situation.
Systems in aircraft often get bits corrupted due to being hit by cosmic rays (I know this sounds like I'm making it up, but run with it). As a precaution there's a few tips like, setting all the unused ROM to cause a reset, ROM/RAM CRC checks, error correction, multiple copies, watchdog, etc. It really kills the available processing power, but that's the price for extra confidence in the system.

<º))))><

I am only one lab accident away from becoming a super villain.

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

wek wrote:
Quote:
So it's pretty robust to "going rogue" - on the whole it'll tend to end up in what looks like a "reset" anyway.

Not that you should rely upon it. The behaviour is oficially undefined, and the mcu is free to do whatever it likes - including fryig itself. Or at least you should treat it so.

JW

The AVR design team would have had to be criminally stupid to create a chip that, if installed blank-from-the-factory into some system, would destroy itself just because power was applied.

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

Quote:

whatever it likes - including frying itself

Ah no - you have to be very careful where you put those HCF opcodes.

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

Quote:
to create a chip that, if installed blank-from-the-factory into some system, would destroy itself just because power was applied.
There used to be a decoder chip in set top boxes that used to that, it was done to stop people cloning it.

<º))))><

I am only one lab accident away from becoming a super villain.

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

Oh, use your imagination... I could quite well imagine an endless loop being factory-installed at the very first two bytes of a "blank" chip...

But, of course they don't do it and it won't catch fire. What I am trying to say is, that a prudent engineer should never rely on undocumented behaviour, however logical might it sound.

JW

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

The Z80 and 6502 (and possibly others) had a few undocumented instructions, it was not unusual for software,mainly games, to use these. These are little nuisances for emulator programmers :)

There are a few software/hardware techniques for hardware fault tolerance. I find this article on Wikipedia quite interesting.

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

I seem to remember that the early PET computers had a fault... err design feature, where if you poked a special value into one location it overclocked one of the ICs so that it rapidly overheated and failed killing the machine.

Quite a bit of military equipment deliberately has self destruct modes. If the equipment case is tampered with, or an interface is wrong in some way, it wipes everything it can then connects the raw voltage onto the PCB frying everything. This is sensible in use, but it makes debugging a bit of a nightmare !

<º))))><

I am only one lab accident away from becoming a super villain.

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

So a new AVR with an illegal opcode vector would be a Good Thing. Any attempt to execute an 0xffff instruction would vector to the handler. You could use this like a system call trap like the swi in the 6800. (Does the pic have an illegal opcode vector Leon?)

Imagecraft compiler user

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

Remember the movie "Runaway"? When the uC was probed, it blew up from the inside... neat idea.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

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

Saw a similar concept on one of the "24" episodes.. self destruct..

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

In one Knight Rider episode, devices melt after being useful or when probed.

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

Quote:

devices melt after being useful

Same thing happened at the start of every episode of Mission Impossible I ever saw ;-)