add one "nop", problem goes away, add another, problem is back.  This 
has got to be an access of memory using an odd address.  Maybe knowing 
this, I can add some nops to my trap routine to force it back into the 
problem scenario so that I could add some debugging stuff after all?

Tony Vandiver wrote:
> OK, this is the worst one I've come across in a while.  I've got a 
> problem with some PIC24 code that seems to be jumping to an AddressError 
> interrupt vector.  It won't do it if I'm in the debugger.  It won't do 
> it if I only have the application code in the chip (must be on top of 
> the bootstrap to happen).  In trying to trap the interrupt, if I change 
> one line of code inside the trap (that I'm trying to use for debugging), 
> it will make the difference between it actually creating the error and 
> not.  Any hints on debugging an address error without a debugger, and 
> without modifying the code?  Level of optimization doesn't seem to matter. 
>
> TIA,
>
> Tony
>
>   
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist