S12x256 - ILLEGAL_BP error

[DRAM]

Hi,

Pretty new to S12x. Seeing ILLEGAL_BP error pop up on my debug window (CodeWarrior). At that point, the Assebmly window shows reads FF13 DEY where FF13 is the address, and DEY? I don't know...

When I looked into other posts that talk abou ILLEGAL_BP error, it says

(a) step through code until you bump into this - and I tried doing this, but it appears that it may be triggered by an interrupt which has not happened yet!

(b) other reason could be unhandled vector. i looked into my vector table. nothing out-of-place. In fact, the memory location FF13 is not even set to contain any vector. Its either FF12 or FF14. FF12 is set to SystemCall. I guess the exception occured at FF12 and the IP got incremented by 1, and froze at that point - right?

Anyways, would be glad if any of you could tell me the steps to proceed to resolve the issue.

Oh yes, by the way, the SP (stack pointer) reads 0 (and IP=FF13). So, it is a stack corruption?  

Thanking you all a lot for your time and  efforts to read and possibly reply to my post...

[isionous]

DRAM wrote: the Assebmly window shows reads FF13 DEY where FF13 is the address, and DEY? I don't know...

DEY is an assembly instruction that decrements the Y register.  The assembly window interprets everything as assembly instructions.  However, FF13 is an address in the vector table and usually contains an address to an interrupt service routine, not stuff that is supposed to be interpreted as code.

 DRAM wrote: I guess the exception occured at FF12 and the IP got incremented by 1, and froze at that point - right?

That's not how interrupts on the S12X work.  I will give a very simplified example.  Let's say the TimerChannel0 interrupt is requested.  The TimerChannel0 interrupt vector is at 0xFFEE, so the S12X grabs the two-byte big-endian word starting at 0xFFEE and interprets that word (let's say 0x5000) as an address.  The PC is then set to that address (0x5000) so that the interrupt service routine (at 0x5000) starts executing.  I've left out a lot of details, but the basic point is that the interrupt vector table contains addresses, not code.  Your IP should only point to code.

Something else is messing with your IP value, which could be caused by tons of things, for instance mismanaging the stack and then doing a return from a subroutine or interrupt.

Also, you should provide information on exactly what microcontroller you are using and if your code is written in C or assembly.

DRAM wrote: step through code until you bump into this - and I tried doing this, but it appears that it may be triggered by an interrupt which has not happened yet!

You could put breakpoints in your interrupts and single-step through your code from there.