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
  • "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!

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

Children
  • Problem is solved !

    Declaring the variables :

    unsigned long volatile v1;
    unsigned long volatile v2;
    
    made the problem disappear.

    Ofcourse i should have noticed the example on page 157 of the keil getting started manual, it says :
    /* note: variables that are modified in interrupts are volatile!  */

    All you said about testing is becoming more clear and actual to me ! :

    I used the same construction of sharing variables between isr's and
    main program several times before
    and never used the volatile declaration!

    How the hell did I never noticed any problems ?

    Bey