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
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 :-)
I'm not blaming anyone. I just know that volatile is a often misunderstood keyword. A volatile too much hurts optimization a lot. A volatile too little can result in totally unexplainable errors.
In a single-tasking PC program, it is possible to ignore this keyword, but in an embedded environment with interrupts and possibly RTOS tasks, it is important to realize the the meaning of it, and that includes both when to use it, and when not to use it.