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.

CCS/CC1350STK: I2C transactions slow down after a CCS debug session is terminated

Part Number: CC1350STK
Other Parts Discussed in Thread: CC1350

Tool/software: Code Composer Studio

Hi,

I have a TIRTOS test application running on the CC1350 sensortag, that reads data from the accelerometer over I2C. This application is built using the Simplelink cc13x0 sdk (1_40_00_10) using CCS v7.1. I am seeing a strange behavior where the time taken to read data over I2C doubles when I am not connected to the target with the debugger.

For example, when I flash and run the code from CCS, my debug output shows that it takes about 1980us to read 60 bytes of data. When I terminate the debugger connection to the target, the same debug output shows that it took about 3850us to read the same 60 bytes of data. It takes the same double speed when I cycle power to the board and let it run without the debugger.

Has anyone seen this or have any idea why I2C transaction speed would be affected by whether the debugger is attached or not? Could it be clocking differences or interrupt latencies or anything else?

I am new to CCS and TIRTOS and this is my first post. Please excuse me if I completely overlooked something.

Thanks!

  • Hello,
    It is quite interesting that the speed is actually faster when in a CCS debug session (normally the complaints are the other way around).

    Now when you mention that you terminate the debugger connection, it slows down, do you mean you start up a CCS session, run the target, notice the speed, then leave the target running while you press the terminate button and then notice the slowdown?

    Thanks
    ki
  • Hello Ki,

    Yes, the sequence you mentioned is correct: I startup a CCS session, run the target, observe the speed, leave the target running while I press the red terminate button. The debug output after that shows the double time for the I2C reads.

    Additionally, the "double time" for I2C is also observed if I just power the board without attaching CCS debugger. I do this by unplugging the USB cable connected to the Debug_Devpack board and plugging it back in.

    I agree it is quite interesting, since it is not uncommon to see timing issues during active debug session. Haven't noticed anything else to be slower, though. Timing around a small block of code returns the same value and the CPU clock freq remains the same at 48MHz. It just appears as if the peripheral clock just halves down when there is no debugger, and I doubt that is what is happening.

    Thanks!
  • Ratheesh Rajan said:
    I have a TIRTOS test application running on the CC1350 sensortag, that reads data from the accelerometer over I2C.

    Does the application transition between Standby and Active Power Modes?

    The reason is that note 3 in the following table in the CC13x0, CC26x0 SimpleLink™ Wireless MCU Technical Reference Manual shows that the Wakeup time from Standby to Active is 200 microseconds shorter when an emulator/debugger is attached:

  • Thank you Chester for pointing this out - the note about debugger and standby. I have the power policy set to PowerCC26XX_standbyPolicy() and enabled, so the system does transition in and out of standby state. I tried to do a quick test to disable the power policy and then I2C reads were failing, but I think that is due to a combination of my code and this particular I2C device. I'll need to do further debugging to resolve it, but this info help set me in the right direction. I'll report back what I find, when I do.

    Thanks!

  • Ratheesh,
    I'll move this thread to the BLE forum. The additional experts there will be able to provide additional insight in regards to I2C.

    Thanks
    ki