This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ILLOPA exception on C167CR-LM

Hello,
I developed an emmbedded application for a C167CR-LM.
In this application I've some very big data structures stored in internal RAM (IDATA) and some dynamic list managed using malloc and free.
For dynamic allocation I define the pool:

unsigned char far equivalence_pool[0x4000];

init_mempool (equivalence_pool, sizeof (equivalence_pool));

In my application there is a IRQ routine on a Timer T6 with a period of 0.5 ms.

In some situations the ILLOPA exception is trapped an the application crashes.
It generally happens when many digital input (linked to port P2 pins) are active together.

I tried to increase the user stack with no effect.

Adding 2 calls to printf in the IRQ routine, ILLOPA is not generated.

Have you some suggestions for help me how to investigate this problem?

Testing with Mon166 the trap routines are not available, and using Simulator is too complex cause the hardware and input sequences to generate.

Thanks,
Marco

Parents
  • I'll repeat myself:

    "f 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..."

    If you know exactly where you came from, it is easier to verify what data you have on the stack and what your trap handler produces.

Reply
  • I'll repeat myself:

    "f 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..."

    If you know exactly where you came from, it is easier to verify what data you have on the stack and what your trap handler produces.

Children