Re: [Simulavr-devel] OxFFFF opcodes

[Theodore A. Roth]

Actually, I think the avr treats all unknown opcodes as a nop.

The attached patch handles this a bit more generically. Give it a try and if 
you are satisfied that it solves your problem, I'll commit it later.

As for wrapping the PC back to 0x0000 on an overflow: I agree that 
simulavr isn't doing the right thing right now, but that's a bit more 
sticky to handle right. The problem is proper handling devices which have 
more the 128K of insn space (thus PC is more than 16 bit). It's not 
impossible to fix this, but I've got to think about it some more.

Ted Roth

On Fri, 13 Sep 2002, ken restivo wrote:

:)I've noticed that my "real" Atmel part seems to skip over 0xFFFF opcodes, 
:)and just proceed on to the next instruction. I've noticed this in testing 
:)my bootloader, and it also is hinted at in the Atmel databook, which 
:)mandates the insertion of .word 0xFFFF after any SPM instruction 
:)(to aid in pipelining, it says).
:)
:)I've added the attached patch to simulate this behaviour of the real part. 
:)
:)This is closer to what the actual chip does, but not 100% complete yet. 
:)It looks like the real chip also will roll the PC off the end of the 
:)flash and back to 0x0000 if a bug sends it into FFFF territory, i.e. 
:)past the end of the program. Haven't found any documentation of that, 
:)but so far it looks pretty reproductible.
:)
:)-ken
:)

sim-unknown-ops.diff
Description: Text document