AVR-Chat

I'm working up what should be a fairly simple Xmodem bootloader.

I've hit some really WIERD problems in execution in a real chip, and 
I thought I'd step back to sim, to see what's going on.

In sim, I get to a point in the code, VERY close to where the real 
app in a chip has problems.. (hmmmm) and the sim complains 
of "illegal opcode $FFFF at location $FF87 (or similar, depends on 
the build)
If I load the lst file, the instruction there is NOT $FFFF, it is a 
perfectly valid return.

The really spooky thing is that as close as I can tell, this is the 
same point that the real app has problems at. 

Is there something wierd about using the last page or so of codespace?
My bootloader orgs to $FE00 and is all done by $FFE6, even with 
debugging support that is almost as big as the bootloader itself.

I could re-org lower, I have ooooodles of space, but that's 
a "voodoo" approach to fixing the problem.

Loaded into a chip, the app gives me wierd problems that shift as I 
include and remove debugging code, as if there was a flag or stack 
problem, but myself, and another experienced SW guy have been over it 
and we didn't catch anything significant.

I'm sending messages on the second serial port to debug, and I am 
using/preserving ELPM during those routines.  Stack pointer IS 
initted, and I'm only using ram up to $0185, with SP at $10FF

00ff80 9350 0102 	sts			XmodemBlk,Expseq
	;	
00ff82 ef0f      	ldi			TEMP,$FF	
		;
00ff83 1b05      	sub			TEMP,Expseq	
		;	
00ff84 9300 0103 	sts			XmodemBlk+1,TEMP
	;
;Above here, I'm faking in a 'received packet' so I can sim through
;verification and programming into the program memory.

00ff86 dedb      	rcall		Get_Packet_Verify	;
00ff87 9508      	ret <--- Here's where it says there's an 
$FFFF opcode..

SP at this moment is $10FD, and will be $10FF if this return would 
actually return...  In sim, the execution drops into some send 
message from rom routines and this behaviour is very very similar to 
what's happening in the real chip.