ILLOPA exception on C167CR-LM

your ISR is miles long. it contains wasteful references to array elements, multiple loops...
try what Per suggested: move the whole block outside of interrupt context - put it in a function and call it from your main loop. what happens then?
again: the fact that code works means nothing beyond that it does not fail on that hardware, under certain circumstance

your ISR is miles long. it contains wasteful references to array elements, multiple loops...
try what Per suggested: move the whole block outside of interrupt context - put it in a function and call it from your main loop. what happens then?
again: the fact that code works means nothing beyond that it does not fail on that hardware, under certain circumstance

I cannot modify the structure of this program.
It's not my property.
I had received this code with this function by the company customer and I removed some unuseful pieces and add a new part.
I cannot split this routine.

Hi Marco,

Back to your original question: what causes the Illegal Operation trap?
You should add a trap handler to collect some debugging information (address of the offending opcode, contents of some CPU registers etc.) Soon you'll be able to map the offending opcode to the exact line of source code.

Regards,
- mike

Small correction.
Just looked it up: ILLOPA is 'Illegal Word Operand Access.' It happens when a word access is attempted at an odd address. Look out for unaligned pointers. The method I suggested should allow you to pinpoint the exact line of source code and the offending unaligned pointer.

Thanks Mike,

so at this moment I've a trap function that, in case of ILLOPA event, print a string "ILLOPA trap!" on serial link.
I can add here a complete printf whith more informations.
Now I try to understand what are the registers or pointers of interest about my problem.

Thank you very much.

Marco

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.