What does opcode 0xFFFF actually do?

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

Hi,

I know that opcode 0xFFFF doesn't really exist, but in some cases (rare, thankfully) where a firmware upload through a bootloader has gone wrong, the CPU must eventually stumble upon the 0xFFFF "opcode".

I have checked the datasheets, searched this forum, and googled the topic. But I still haven't found what I'm looking for. (Sorry about that, Bono. Couldn't resist.)

So, I'm asking you guys: Anybody know what an AVR will do when trying to process opcode FFFF? Skip it and read the next, like a NOP? Freeze? Reset?

Best regards,
ErikT

You're absolutely right. This member is stupid. Please help.

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

Search for a thread by "Brutte" where this was explored and explained previously.

EDIT: OK it is "sbrs r31,7" so how it behaves depends on what's in bit 7 of R31. It either executes every opcode or every second one.

EDIT2: actually the discovery seems to date back to at least 2004: https://www.avrfreaks.net/index.p...

Last Edited: Fri. Aug 31, 2012 - 10:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Step through it with JTAG and see for yourself.

No. I have not bothered to.

At a guess, it behaves as a NOP. Most modern CPUs will do nothing for an 'un-implemented' opcode.

In the old days, a 6502 would do 'strange things'.
A 68000 would raise an exception for 'line-F' and 'line-A' opcodes. This could be used to 'expand' the 'features' like a Maths-co-processor.

Untested. Reaching into my distant memory.

David.

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

Quote:

At a guess, it behaves as a NOP

Nope this was the common misconception. It is actually SBRS R31,7. While you might have spotted this with JTAG it would be pretty fortuitous to see that bit 7 of R31 was relevant!

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

Quote:
A 68000 would raise an exception for 'line-F' and 'line-A' opcodes. This could be used to 'expand' the 'features' like a Maths-co-processor.

IIRC the Apple Macintosh used these opcodes as entry points into the OS.

It's funny how the AVR studio 4.16 disassembler does not know about opcode 0xFFFF. SBRS R31,7 seems like a valid instruction.

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

Quote:

SBRS R31,7 seems like a valid instruction.

Well just to confuse things further the current opcode manual says the bit pattern for SBRS is:

1111 111r rrrr 0bbb

So while rrrrr and bbb may be 1's that has a 0 in it.

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

Officially the SBRS opcode is : 1111 111r rrrr 0bbb

So perhaps bit3 is treated as don't care.

If if does behave as SBRS, then an "empty" mega128 would take 65536 cycles to get back to where it started. i.e. 4.096ms @ 16MHz

The SBRS would either go in 2-word steps @ 2 cycles or 1-word steps @ 1 cycle. i.e. "almost" the same as an even number of NOPs.

So a human is never going to notice whether a bootloader starts directly with BOOTRST, or 4ms 'late' because it skipped throgh an 'empty' application.

David.

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

Quote:
OK it is "sbrs r31,7"

Ooooh. That's weird. Sounds like somebody cut a corner somewhere.

Thanks for your "Brutte" tip. Apparently, the forum search thing doesn't find articles with 0xFFFF, when I search for FFFF. Got it now.

You're absolutely right. This member is stupid. Please help.

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

Just to note that the official NOP opcode is

0000 0000 0000 0000

It would be a simple matter with a utility such as Srecord to have "blank areas" in a .hex padded to hold 0x0000 rather than just rely on the 0xFFFF erased default value in flash if one was really paranoid about such things.

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

Quote:
Ooooh. That's weird. Sounds like somebody cut a corner somewhere.

In what sense? What do you think should have been done?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

If CPU designers did not skimp on the full opcode decoding the Z80 would never have got the IXH/IXL/IYH/IYL instructions!

http://www.z80.info/z80undoc3.txt

The plan was that the DD/FD prefixes (for example) would just cause an HL opcode to act on IX or IY but it turns out that because of incomplete decode it also affects all the separate H and L opcodes to allowing for IXH/IXL/IYH/IYL operations.

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

Quote:
If CPU designers did not skimp on the full opcode decoding the Z80 would never have got the IXH/IXL/IYH/IYL instructions!

Not that I know exactly what that means, but I understand that it has something to do with "accidental", but useful, instructions.

I think it is different with the 0xFFFF in the AVR. You don't get an extra, useful instruction. You rather get a "maybe-NOP", and you may get the microcontroller to reset, if you don't have bootloader code, or something else placed in the higher end of the flash.

Maybe it's just me, but I'd rather have the microcontroller freeze when hitting a 0xFFFF. Better that, than crashing into some data, or into the bootloader.

You're absolutely right. This member is stupid. Please help.

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

It's an unfortunate error in the initial microcode, I wish they would have fixed it in newer AVR's when they changed the documentation. As it stands now, if using a bootloader, it is adviseable to place a NOP right before the bootloader vector table to ensure that the bootloader reset vector is not skipped.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

It's not "HCF" (Halt and Catch Fire)?

The largest known prime number: 282589933-1

In my humble opinion, I'm always right.