Hello, After two years of happy working with the keil C166/C167 compiler I've just ran into a problem I don't understand / can't solve. Running phytec kitcon 167 Memory model Hlarge Declared two unsigned long variables :
unsigned long v1; unsigned long v2;
if (v1!=0) { v2 := v1; ..... ..... }
MOV R6,DPP2:0x1750 MOV R7,DPP2:0x1752 MOV R4,R6 OR R4,R7 JMPR CC_Z,0x003A3C MOV DPP2,0x1776,R6 MOV DPP2,0x1778,R7
if (v1!=0)
v2:=v1
Hi Sander, The most likely reason for the strange behaviour is the rest of your program that we can't see in your posting. If your program uses interrupts and/or multiple threads, then there is your answer. ISRs can do all sorts of strange things, for instance modifying GPRs, and even stranger things have happened. Watch out for PECs too. - mike
Hi Mike, The program indeed uses several isr's but these never caused this kind of problem before. Also PEC's are used , one system for A/D conversion ; the other for sending data to the serial port. Without the serial PEC system and the 'longint problem part' the program has been working perfect in several versions over a period of 1 year. I will look into the user manual for PEC details. Thanks, S.Nijssen
"The program indeed uses several isr's but these never caused this kind of problem before." Just because a problem has not manifested itself before doesn't mean that it's not there! Maybe you've just never noticed it before! More likely, you've just been lucky so far - and just not happened to hit the precise set of circumstances necessary to trigger the problem! Beware the "Proven Product Syndrome:" http://www.8052.com/forum/read.phtml?id=55408 "the program has been working perfect in several versions over a period of 1 year." I've just found a bug in some code that I wrote that had, apparently, been working perfectly for several months. Having found the bug, I could only say, "How on earth did that ever work at all??!!"
I could only say, "How on earth did that ever work at all??!!" I think this has to be one of the top ten phrases heard in the lab, second only to "But what could be different?" Here's my own example. Look halfway down this thread at the code snippet I posted for an interrupt-masking prologue: http://www.keil.com/forum/docs/thread3030.asp Just last week, I noticed in my actual code that I had somehow (somewhy?) written "SETB EA" instead of "CLR EA", thus guaranteeing that interrupts couldn't possibly be masked in the critical section. Nevertheless, I've made it the last three months without really noticing this bug. "How did that ever work?" One lesson to be learned is that testing, alone, is not sufficient proof that your system is correct. Not all bugs like to show themselves in the lab, and passing even a good test suite doesn't mean the bugs are gone. Analysis and inspection help, too. But back to the point: If these longs are shared between an ISR and the main code, volatile would be appropriate. Here's a couple of past threads discussing what volatile does and when to use it. http://www.keil.com/forum/docs/thread2166.asp http://www.keil.com/forum/docs/thread3129.asp
Hello Drew, I'm sure you set me back on track, I'll test it tomorrow morning and let you know. p.s. I noticed my own 'C' errors in the source line
v2=v1
View all questions in Keil forum