MSPM0G3507: CCS watch window register not match with runtime result

Dear expert, 

We can duplicate this. 

Here is my testing, I create three variables to get the I2C Slave Register in different ways and timing. 

u32temp1 => From the API

u32temp2 => From the memory location for the register

u32temp3 => From the API after running 100 cycles

            DL_I2C_flushTargetTXFIFO(I2C_INST);

            u32temp1 = DL_I2C_getTargetStatus(I2C_INST); //API read slave register

            u32temp2 = *(uint32_t *)0x400F325C; //read the slave register memory location value

            for(int i=0;i<100;i++)
            {
                __NOP();
            }

            u32temp3 = DL_I2C_getTargetStatus(I2C_INST); //the value stabled

            __NOP();

            break;

• Breakpoint before running the for loop
  • u32temp1 & u32temp2 = 0x0009040,
  • Address 0x400G325C = 0x00009000
  • I2C_SSR = 0x00009000
     
    
    
• Breakpoint after running the for loop, it becomes stabled
  • u32temp1 & u32temp2 = 0x00009040,
  • u32temp3 = 0x00009000
  • Address 0x400G325C = 0x00009000
  • I2C_SSR = 0x00009000
    
    
    

Shouldn't the value we get from memory the same as we saw from the memory browser?

Best Regards,

Eric Chen

The example i2c_controller_rw_multibyte_fifo_interrupts doesn't appear to read any of the Target-side status (since it's running as a Controller).

Supposing this is actually something like i2c_target_rw_multibyte_fifo_interrupts, I suspect you're seeing a race between the target-side I2C unit and the debugger. Even with PDBGCTL=0, I expect the I2C unit can take some finite time to halt at a breakpoint, so something very dynamic like BUSBSY (0x0040) could change in the meantime.

I suggest you mask off the fields you're not interested in before comparing.

Hi Bruce,

There was a typo. Yes, we are talking about Target side (G3507 I2C acts as target) rather than Controller side and I already changed the path in the first post.

Would you please make it clearer "a race between the target-side I2C unit and the debugger"?

Do you mean even we set a breakpoint right after var = DL_I2C_getTargetStatus(I2C_INST);, but the debugger still could not get it at the same time?

That is, you meant the CCS window result is not correct at the breakpoint?

You mentioned "I suggest you mask off the fields you're not interested in before comparing." In fact, we were only trying to get the R/W bit right after the address, and found it was hard to identify it by comparing our codes and CCS watch window.

Do you have any suggestion how we should do here if we want to get the R/W bit? Would you please elaborate it?

Is this a CCS bug or a debugger (XDS110) limitation?

Hi Bruce,

This is resolved by the above method + loop-based statements.

Thank you for your information.