We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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 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
Hi Andy, I confirm your statement about running/testing a program with a lot of isr's. For my project I used to drive all isr's with independent signal generators on their input pins. All the measurement data is then transmitted through the serial port. All is received by a windows program that performs all kind of validation on the data. If errors are found they are logged by the program. Running these kind of tests during the night gives you valuable data about the system. This way I also spotted my problem at first. Sure the method does not guarantee that the program is flawless but it has worked fine for me. Thanks for your comment
"For my project I used to drive all isr's with independent signal generators on their input pins." Yep, that's a good stress test, but my point still stands: the fact that you didn't detect any problems does not guarantee that there are no problems. eg, i had a problem a while back where a certain event was occasionally mis-handled. To capture the behaviour, I connected up all the logging stuff like you, and increased the event rate in the hope that the error would manifest more often. It didn't; in fact, it totally stopped happening! It eventually turned out to be an interaction with a background activity lasting 20 seconds or so, and occurring only when the system had been "idle" for 5 minutes or so - so increasing the event rate actually stopped the problem from manifesting! Heisenberg strikes again! I'm not trying to say that testing is worthless; just pointing out that statements like "It's been working for xx months without a problem" are not sufficient to conclude that there are no bugs still lurking!
Problem is solved ! Declaring the variables :
unsigned long volatile v1; unsigned long volatile v2;
/* note: variables that are modified in interrupts are volatile! */