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.
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.
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
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.
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.
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.
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.
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.
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.
"Lewin A.R.W. Edwards" skrev i meddelandet news: snipped-for-privacy@posting.google.com...
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
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.
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 This is a personal view which may or may not be share by my Employer Atmel Nordic AB
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, bsd@bdmicro.com BDMICRO - Maker of the MAVRIC ATmega128 Dev Board http://www.bdmicro.com/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.