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.

TMS320F28P650DK: Unpredictable behaviour of if condition after changing optimization.

Part Number: TMS320F28P650DK

Hi Experts , 
I had declared

 volatile uint16_t status2;
#define ESC_EEPROM_STATUS_EEPROMLOAD_M 0x1000U
#define ESC_EEPROM_SUCCESS    0x0U
 
When I am adding no op instruction in else part its going into line "return (esc_eeprom_success , screenshot 2 "after condition check , otherwise without no op its going into its going to line ("esc_eeprom_load_error" , screenshot 1) . Can you help me clarify. If everything is correct with or without no op it should go to line with ("return esc_eeprom_sucess") statement. (check_status3 is added to watch expression for debugging.)


  
 
Similar to e2e , https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000-microcontrollers---internal/f/c2000-microcontrollers---internal-forum/1608054/tms320f28034-f28034-the-program-takes-the-wrong-branch-path
Can you please help me understand this behaviour?

Also please suggest way of solving the issue without nop or delay.

(Found this explanation using llm)


  
I have created a simple program to recreate the issue with only those lines of code for reference and attached, same behaviour is observed :
device : f28p65x launchpad
optimization : 2
  • Also just to add the flow is correct in optimization level zero irrespective of nop instruction.

  • Does the program perform the expected operation? Or is this just a concern with where the debugger is placing your cursor?

    I compiled your test case without the NOP and believe the code is valid. SUCCESS is returned if bit 12 of status2 is 0, and ERROR is returned otherwise.

    However, an optimization moves code in such a way that the debugger believes it's in the ERROR case while checking bit 12 of status2. If the check succeeds, it will still return SUCCESS.

  • Sorry I did not get your last point regarding optimization . (Are you suggesting debugger might be placing cursor on wrong position , but the end result will be correct ?)

    The same piece of code is working fine for c29x compiler with or without no op. But for c28x compiler its making a difference. 

  • I am suggesting that the debugger is placing the cursor precisely where the compiler told the debugger to place it, so there is no bug in the debugger to be clear. This location changes due to optimizations performed on the code, and may not be source-accurate. While the location is not accurate, the meaning of the code hasn't changed.

    Can you define what "working fine" means? If you're speaking of the cursor's position in the source during debug, then I would assert that the code is executing correctly, unless you have observed otherwise. Debug information does not define what the program does, it's only an approximation, especially when optimization is turned on.

    The comparison to the C29x compiler is not effective because the two are completely different compiler toolchain infrastructures. C29x uses the open source Clang/LLVM infrastructure, while C28x uses the proprietary TI infrastructure. The way the two toolchains generate debug information will be different.

    If you're familiar with C28x assembly, I can try to explain what you're seeing. However, unless the program is actually returning ESC_EEPROMW_LOAD_ERROR, as in the return register is set to -2 upon exit of the function, then there's no issue.

  • Understood your points. I have tested it on my side also . 

    Thanks James.