• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 82 subscribers
  • Views 431 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.

Original question:

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

Compiler/TMS320F28235: ASM help on the code

Jordan Zhou
Genius 10470 points

Part Number: TMS320F28235

Tool/software: TI C/C++ Compiler

Hi,

In customer's code, they faced one issue on a global parameter, which is used by both main loop and ISR, but not volatile. 

They found that, very few times, the parameter value couldn't be changed by ISR successfully. The value may be covered by main loop instruction. 

They did a test. The details are:

1) In the main loop, the code continuesly writing the parameter with a value: gMainStatus.ErrorCode &= ~ERR_24VVTG_LOW (macro defined).

2) In the ISR, gMainStatus.ErrorCode |= ERR_24VVTG_LOW.

ISR is triggered frequently. Few times, after ISR (gMainStatus.ErrorCode |= ERR_24VVTG_LOW), before a new assignment in main loop (gMainStatus.ErrorCode &= ~ERR_24VVTG_LOW), gMainStatus.ErrorCode was still the value from mian loop (gMainStatus.ErrorCode &= ~ERR_24VVTG_LOW), but not the one from ISR.  

From disassembly side, we'd like to know if it's possible.

Here's the disassembly. 0xbd50 is the address of the struct. #8 is the offset of ErrorCode. 

We don't understand the code in  00a7fc. If it's just one cycle instruction, that ussue may not happen. As, if during main loop  instruction gMainStatus.ErrorCode &= ~ERR_24VVTG_LOW, ISR happens, gMainStatus.ErrorCode's values is changed. If there's no restore after ISR, the issue may not happen. 

Thanks a lot.

Br, Jordan

  • 0
    TI__Mastermind 27200 points

    Jordan,

    Yes, this is possible. The issue is similar to the one in your referenced thread.

    The bit-wise AND operation with immediate operand seems not to be read-modify-write, so it is possible to have this corruption.  To prevent it, you can either disable interrupts around the instruction, or use the __and intrinsic which George suggested in the other thread and is atomic.

    Regards,

    Richard