Undefined opcodes on AVR?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

Hi,

Does anyone here know what happens when an AVR microcontroller executes
an undefined opcode (such as 0x0001)? I've looked in a few ATmega
datasheets and the AVR instruction set manual without finding any
specified behavior.



Re: Undefined opcodes on AVR?
Quoted text here. Click to load it

I hate to not answer your question, but it brings to mind stories from
20+ years ago about undocumented opcodes on 8080's and 6800's. Sorry
just a little nostalgia trip... Now back to your regular programming.


Re: Undefined opcodes on AVR?
Quoted text here. Click to load it

Not to state the obvious, but if you'd find them in the manual, they
wouldn't be 'undefined' anymore, would they? Do as the Z80 folkes used to
do, try it and see what effect they have.

Rob



Re: Undefined opcodes on AVR?

Quoted text here. Click to load it

Well you see I kind of expect vendors to define what their products do,
or at least explicitly say "in that case, the behavior is undefined".

I have even been harboring a secret hope that the behavior is to trap
or otherwise signal that a problem has been encountered, but perhaps
sanity is too much to ask for.


Re: Undefined opcodes on AVR?

Quoted text here. Click to load it

   What they may explicitly say is "any opcode not listed is
undefined." Even if they don't, I'd assume that myself [that anything
not explicitely documented is undocuimented], rather than using
something undocumented [by the manufacturer] and having it bite me in
a very sensitive area (my wallet) later.

Quoted text here. Click to load it

   It likely takes extra decoding circuitry and thus 'too much'
silicon area to decode illegal opcodes to one or more trap addresses
(I recall Motorla devices (68xxx series, and did some others do this?)
being good about decoding everything and sending the program counter
to an appropriate vector).
   While developing code for a DSP (Zilog's Z893x1 when it was new,
I'm surprised they still make it), I one day ended up with a program
that was voltage-sensitive. The chip was spec'ed for 4.5V to 5.5V or
so, but what it did changed at around 4.95V. After a few days'
examination I discovered an instruction/addressing mode combination I
was using that wasn't actually legal for the processor, but the
(USD$600) assembler gave no error message but generated code for it
anyway, so it gave no clue that I had made a boo-boo. When I fixed the
code it worked fine and consistently as expected throughout the chip's
voltage range.
   I had a hard time AVOIDING an undocumented opcode. I would never
intentionally use one, and not just because of that bad experience.
Since it's undocumented, the next batch of chips could do something
totally different with the same undocumented opcode, and if you
complain, the manufacturer can (or rather WILL) tell you the new chip
is within spec, and you're using it outside of spec - it's YOUR
problem.
   RTF Data Sheet.

Re: Undefined opcodes on AVR?

Quoted text here. Click to load it

Of course.


If that's the case, then reliability is 'too much' to ask for.
It is possible for a microcontroller to get a munged instruction
in any environment. I suppose the Atmel-preferred solution to this
problem is either of the 'power cord' or 'reset switch' technologies.

The 65c02 core consists of 3244 gates and no-ops all 'unused' opcodes.
IMO, this is preferable to undefined results. Even though it does
nothing to prevent the system from crashing, you are less likely to
read/write the wrong thing from/to the wrong place.

Quoted text here. Click to load it

Me neither. I don't want to use undocumented opcodes, I want to know
what happens when an undocumented opcode is executed, even though I
don't want it to happen.


Re: Undefined opcodes on AVR?
Quoted text here. Click to load it

Many microcontrollers in AVR's target market space don't have an
unimplemented instruction trap, though. And it won't protect you very
much against PC corruption, or code memory corruption. Periodic code
checksums, a non-disableable WDT, external hardware interlocks so that
hazardous external events can only be ordered by following a strict
sequence of output states, etc. etc. etc. etc.

When cosmic rays strike, interlocks will prevent your application from
foaming at the mouth and slaughtering users. The WDT will restart your
system and bring it back to its feet. An unimplemented instruction
trap won't add a whole lot to that.

Re: Undefined opcodes on AVR?

Quoted text here. Click to load it

The AVR won't trap but there is no undocumented HCF instruction either.
HCF = Halt and Catch Fire.
The trick is as Lewin says, to have a watchdog that cannot be disabled.
That may be implemented in future AVRs.
Today it is hard, but not impossible to disable the "mutt".
/Ulf S
Atmel



Re: Undefined opcodes on AVR?

Quoted text here. Click to load it

The watchdog timer is helpful, but it doesn't tell you what caused
the microcontroller to crash. In any case, I guess I have received
the answer to my original question.


Re: Undefined opcodes on AVR?
Quoted text here. Click to load it
You will in modern AVRs see that there is a register that tells you the
reason
for a reset.
Since most status has not changed as a result of reset, you may be able
to maintain a continuous log of what you are doing, and report that
somewhere after
you have the mutt fire.



--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Undefined opcodes on AVR?

Quoted text here. Click to load it

The ATmega128, at least, has this.  It is enabled by programming the WTDON
fuse bit in the extended fuse byte.  When that bit is programmed, the WDT
is always on and cannot be disabled.  Unless, of course, a cosmic ray zaps
the fuse bit :-)

Cheers,
-Brian
--
Brian Dean, snipped-for-privacy@bdmicro.com
BDMICRO - Maker of the MAVRIC ATmega128 Dev Board
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline