• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 516 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/TMS320F28235: Parameter value lost, how to find the code where it's changed

Jordan Zhou
Genius 10470 points

Part Number: TMS320F28235

Tool/software: TI C/C++ Compiler

Hi,

Customer's code faced one issue. Global parameter abc's value was changed, but we don't know where it was changed. 

The logic is like that:

main()

{

   if(condition==true)

       abc &= ~def;

}

isr()

{

   abc |= 0x10;

   hig=100;

}

During about 1000 times test, we found  that abc's value lost (still "0") after isr() execution (as parameter hig equals 100). Other 999 times, after isr(), abc's bit 4 is 1. That means, most of the times, the logic works well. But very few times, abc loses its value. 

We are working for severl test cases to find the root cause, although it's very hard to reproduce. 

Here, we have a doubt: if abc &= ~def; is under executing (currently abc=0), before finishing, if an interrupt comes (inside abc|=0x10), what will happen after restore from isr and abc &= ~def finishes executing. Will abc still be 0 or 0x10?

abc &= ~def, in ASM, there are 5 lines code (just an example). During line 4 code, an interrupt may come. We'd like to know what will happen after isr and line 5 code. 

Hope I'm clear.

Thanks a lot.

Br, Jordan

  • 0
    TI__Mastermind 27200 points

    Jordan,

    I think you are on the right track. The issue is likely because abc &= ~def is not coded to be atomic: that is, if an interrupt occurs after 'abc' has been loaded into a register, the context save will protect that and restore the old value after the ISR. In that case you would lose the effect of the bit-wise or inside the ISR, but this will only happen if the interrupt gets taken on exactly the right line, which is why it's so rare.

    To test this, and as a possible work-around, you can disable interrupts for that line:
    DINT;
    abs &= ~def;
    EINT;

    Alternatively, if you are implementing that line in assembly, make use of the atomic "read-modify-write" AND operation:

    AND loc16, AX

    I hope this helps.

    Regards,

    Richard

    C28xm01 slide 6.pdf

  • 0
    TI__Guru**** 253380 points

    With regard to variables changed by interrupts, there are two details you need to address.

    One ... Every global variable that is changed by an interrupt must be marked with the volatile keyword.

    Two ... To guarantee operations like ...

    Jordan Zhou said:
     abc &= ~def;

    ... are performed atomically (which means the operation cannot be interrupted) use intrinsics the compiler supplies for this purpose.  In this particular case, you write something similar to ...

        __and(&abc, ~def);

    To learn about __and, and other intrinsics like it, please search the C28x compiler manual for the sub-chapter titled Using Intrinsics to Access Assembly Language Statements.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Genius 10470 points

    Thanks for your comment.

    Another doubt, do we have any tool to see if parameter abc's RAM address is operated by other parameter, by mistake?

    In this case, the value can also be changed. 

    br, Jordan

  • 0 in reply to Jordan Zhou
    TI__Mastermind 27200 points

    Jordan,

    You can do that on C28x by setting a watch-point on the data memory address of interest.  I don't know which CCS version you're using, but in the v9 debug perspective you'll do this:

     - Double-click on the variable name in your code to highlight it

     - Right-click and select Breakpoint -> Hardware Watchpoint

    You've now set a Watchpoint on a data memory address.  Run the code and it should stop on each access to that variable.  To view and change the Watchpoint:

     -  From the CCS menu: View -> Breakpoints

     - Right-click on the Watchpoint and select Breapoint properties

    You'll see the symbolic address and other settings.

    Regards,

    Richard

  • 0 in reply to Richard Poley
    TI__Genius 10470 points

    Richard,

    Thanks for your comment. 

    During the test, the emulator is not connected. let me think how to do through data communication.

    Br, Jordan

  • 0 in reply to Richard Poley
    TI__Genius 10470 points

    Thanks Richard.

    Br, Jordan