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

problem with unsigned long variables

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;
problem part of code :
if (v1!=0)
  {
    v2 := v1;
    .....
    .....
  }
At regular intervals but only once in
200 .. 1000 times the code loses the two
least significant bytes op v1.
e.a.
v1 : 0x0001 5BC9
normal outcome , v2 : 0x0001 5BC9
false outcome , v2 : 0x0001 0000

memory location of v1 : 0x0004 1750
memory location of v2 : 0x0004 1776

Behavior in simulator looks like behaviour on the board.

I've looked at the disassembly :
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
for
if (v1!=0)
the compiler stores value in r6 and r7
When error occurs r6 is good in line
if (v1!=0)
but is cleared ! before line
v2:=v1
is executed.
r6 was holding two least significant bytes.

Can anybody help ?

Best regards,
S.Nijssen
Motoplex

Parents
  • 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

Reply
  • 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

Children