ILLOPA exception on C167CR-LM

See the MCU manual. The C167 CPU will push PSW, CSP and IP onto the system stack. Print them. CSP and IP will point to the offending instruction. Using a disassembler, you'll be able to map the instruction to the source code.

See the MCU manual. The C167 CPU will push PSW, CSP and IP onto the system stack. Print them. CSP and IP will point to the offending instruction. Using a disassembler, you'll be able to map the instruction to the source code.

More thanks.

Marco

Hello Mike,

I looked to User Manual but is written that IP and CSP are not directly accessible, so how can I print IP and CSP?

Thanks

I looked to User Manual but is written that IP and CSP are not directly accessible

You mean this, right?
The IP register is not mapped into the C167CS's address space, and thus it is not directly accessible by the programmer

That's true, but why would you want to read IP in the trap handler? It will not do you any good.
You don't need to read the actual registers. You need the contents of those registers at the time when the trap occured. And those are saved on the stack by the CPU (see manual, section on trap functions.) If I remember correctly, Keil's C166 compiler has an intrinsic function for popping words off the stack. _pop_(), maybe? Look it up. Here is what I would do:

void trap_handler(void)
{
  uint16_t psw, csp, ip;
  ip = _pop_();
  csp = _pop_();
  psw = _pop_();
  ... print psw, csp, ip ...
}

You are correct.

Summary: #include <intrins.h>
int _pop_ (void);
Description:
The _pop_ function inserts a POP instruction into the program which pops the next word from the system stack.
Return Value:
The _pop_ function returns the 16-bit value poped from the system stack.

Example:

#include <intrins.h>
void testpop (void) {
   volatile unsigned temp;
   _push_ (temp);
   temp = _pop_ ();
}

you may want to have a look at the Keil provided traps.c file, too.

Yes, Ok.

I've in my project a custom version of traps.c.

Using the calls to _pop_ function I will insert them in a function called by ILLOPA trap in my traps.c.

Thanks.

Using the calls to _pop_ function I will insert them in a function called by ILLOPA trap in my traps.c

Be careful, though. Each function call pushes more data onto the stack. You have to account for that when trying to extract the saved PSW, CSP, IP. The three simple pops will not do.

You are correct, it's a problem.
I will try to find a solution.

Thanks!

If a ILLOPA represents an 'Illegal Word Operand Access', then I recommend that you test your trap handler by intentionally doing an incorrect access, and verify that the data you get do point to the correct position in the code. You may loose a lot of time if your trap handler is buggy and prints the wrong address, and you then spend time trying to figure out why a completely different location contains a problem...

Ok, thanks.

one more important thing:

#pragma NOFRAME // gain full control over stack push/pop instructions of the interrupt handler
static void task_switch() interrupt 0x20

notice the #pragma. placed before a function, it will prevent the compiler from automatically generating code that saves your registers onto the stack thereby not polluting it.

Ok.
I've updated my Class_B_trap function in the customised file traps.c with the red code below.

#pragma NOFRAME
void Class_B_trap (void) interrupt 0x0A  {
     volatile UINT reg_ip;
        volatile UINT reg_csp;
        volatile UINT reg_psw;

        reg_ip = _pop_();
        reg_csp = _pop_();
        reg_psw = _pop_();

        printf("IP: %X, CSP: %X, PSW: %X\n\n", reg_ip, reg_csp, reg_psw);

        if (ILLBUS) puts("Accesso a bus esterno non valido");
        if (ILLINA) puts("Accesso ad istruzione non valido");
        if (ILLOPA) puts("Accesso ad operando non valido");
        if (PRTFLT) puts("Istruzione di protezione non valida");
        if (PRTFLT) puts("Codice istruzione non definita");
        ERRF = 1;
  while (1);                 /* end-less loop */
}

So the value of reg_ip combined with the reg_csp value will be the address of the instruction following the one which caused the trap.
Is it correct?

Why do you declare your variables volatile? Are you expecting them to be changed by memory corruption or?

The keyword volatile should be used for a global variable that may asynchronously changed by someone else, such as an interrupt handler or a a different thread.

An auto variable should never be changed asynchronously unless you have a memory corruption somewhere, allowing an interrupt or thread to play with stack memory they do not own.

By the way: Think about using an unified intentation strategy. Your code has three different indent levels and/or mixings of space and tab. That doesn't help readability.

Why do you declare your variables volatile?

Oh please! Obviously, the guy is only interested in fixing this particular bug. He's got a fair share of advice on programming style already in this thread.
Apparently, volatile comes from here:
http://www.keil.com/support/man/docs/c166/c166__pop_.htm

So blame Keil for this. I, too, cannot see why they would declare the variable volatile. Except, perhaps, 'just in case'...

Mike,
I think Per's latest comment are very much appropriate. The OP (assuming he is not aware of the impact of volatile, of course) might have gotten the false impression that volatile is somehow required, and start using it regularly (thanks to a weird example by Keil, indeed). That will have a negative impact on the performance and size of his code. And who knows, if somebody ever proved him wrong, he would have given us a bad name :-)