• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 55 subscribers
  • Views 4039 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.

CCS/TMS320F28069M: Debugger halts at I2C interrupt

Jakub Klein
Intellectual 630 points

Part Number: TMS320F28069M
Other Parts Discussed in Thread: CONTROLSUITE

Tool/software: Code Composer Studio

Hello,

I'm trying to run the I2C module on my Piccolo MCU. I have prepared a HAL driver similar to the other ones with a help of an I2C example from ControlSUITE, but my version encounters a problem I cannot understand.

There is an ISR to send a STOP condition triggered by ARDY bit, similarly as in the example. After sending first byte, CCS goes into the ISR and halts at the place where I would clear the NACK Interrupt bit in I2CSTR register. See a screenshot of how it looks like (note that I didn't create any breakpoint there!). If I delete the 'faulty' line, the same thing will happen at the first 'if' condition. The data byte seems to be sent properly (see the next screenshot of logic analyzer), but nothing more is being sent when I resume the program.

Two basic questions:

1) What may cause the debugger to halt without a breakpoint? Can I track a source of the problem from here?

2) Any idea on what can be the reason for such behavior with I2C module?

An interesting thing is that: after taking a look at the Mode Register when the program is halted, it seems that the MST bit  got cleared - what means that my MCU changed state from Master to Slave - how is it possible!?

---------------

CCS window that halts at the highlited line:

CCS Screenshot

And the logic analyzer window:

Logic analyzer

  • 0
    TI__Guru**** 480691 points

    Hello Jakub,

    I can't comment too much about the other questions specific to the device and I2C module. The C2000 experts can handle those. I have brought this thread to their attention.

    Regarding the below question however:

    Jakub Klein said:
    1) What may cause the debugger to halt without a breakpoint? Can I track a source of the problem from here?

    The debugger would normally not halt unless some kind of breakpoint is reached, or a halt command from the debugger (this can also be triggered by a watchpoint). Can you post a screenshot of the debug view when this happens? It should mention the reason of the halt there.

    Thanks

    ki

  • 0
    TI__Mastermind 45606 points

    Hi Jakub,

    As you step through your program and watch the I2CSTR.bit.NACK bit in the expressions window, does it change while in your if statement? Or does it stay 1 or 0? Might want to try observing the entire I2CSTR register to understand what's going on. I'm not sure why it's halting on that line and will need further investigation to figure out.

    I think the MST bit being cleared is OK since you are generating a stop condition right before it changes, read below:

    Best,

    Kevin

  • 0 in reply to Ki
    Intellectual 630 points

    Thank you all for the responses,

    @Ki-Soo: Here is a full screenshot of the CCS window. How can I track the reason for haltin, where to look for it? Is it something that can be seen at the 'debug' window?

    ----------

    : Please, take a look at the screenshot below that shows STR and MDR registers at different stages (as I step through the code in the debugger). It seems that NACK flag is clear all the time (I don't have any device connected, just the external pull-up which doesn't change anything now).

    Registers

  • 0 in reply to Jakub Klein
    TI__Guru**** 480691 points

    Jakub - your screenshot seems to indicate some SW breakpoint triggered the halt:

    Can you open the Scripting Console and enter the following command:

    js:> eval("DEBUG_DumpBreakpoints()")

    This should output some information in the Debug Console. Please provide the output here.

    Thanks

    ki

  • 0 in reply to Ki
    Intellectual 630 points

    Dear Ki,

    Please, take a look at the attached file where I copied the output of the scripting console. I run your command during the halt.

    /cfs-file/__key/communityserver-discussions-components-files/81/I2C-breakpoints-_2D00_-scripting-console-output.txt

  • 0 in reply to Jakub Klein
    TI__Guru**** 480691 points
    The output indicates that there is only one breakpoint active and that is at the exit point of the application (which is expected).

    What is the contents of the disassembly window at the location of the PC at the time of the halt
  • 0 in reply to Ki
    Intellectual 630 points

    Below is a screenshot of disassembly window, but I also copied the content to a text file in case you need a bigger picture:

    /cfs-file/__key/communityserver-discussions-components-files/81/I2C-_2D00_-disassembly-window-content-at-halt.txt

    diassembly

  • 0 in reply to Jakub Klein
    TI__Guru**** 480691 points

    An ESTOP is a software breakpoint instruction. 

    This would answer the question on why the target is halting at this address.

    Now the question becomes: why is there an ESTOP instruction at the address? The debugger is unaware of any SW breakpoint at that address so it was likely not set by the debugger.

    ki

  • 0 in reply to Ki
    TI__Guru**** 480691 points

    Jacob - in your screenshot of the debug view, I see the program halted at line 233 of main.c - which is address 0xCFA4

    But in the disassembly view, the program is halted as 0xD0DC. Why the discrepancy?

  • 0 in reply to Ki
    Intellectual 630 points

    I'm not sure, maybe I have added something to the code between those two posts. I checked it now and the Debug window says it's halted at line 233 (0x00D0DC), what corresponds to the Disassembly line with ESTOP0 command.

    Think I've found this command in the C-code. If you take a look at the screenshot of my code from the first post, you will see there's an "else" command - but the screenshot doesn't show what's inside it. A full picture would show the rest:

           else
       {
          // Generate some error due to invalid interrupt source
         __asm("   ESTOP0");
       }
} //end of i2cISR

    After I comment-out this ESTOP0 command, the program doesn't halt. So it's probably this breakpoint it hits and the disassembly code miraculously assigned it to a wrong line of the main.c.

    I will dig into it deeper tomorrow, but commenting out this line doesn't help with the I2C itself. It still doesn't work for more then the first transmit, even though the program doesn't halt.

  • 0 in reply to Jakub Klein
    TI__Guru**** 480691 points

    Jakub Klein said:
    If you take a look at the screenshot of my code from the first post, you will see there's an "else" command - but the screenshot doesn't show what's inside it

    Actually your second screenshot earlier *does* show it but I didn't pay attention and completely missed it (argh). 

    Jakub Klein said:
    I will dig into it deeper tomorrow, but commenting out this line doesn't help with the I2C itself. It still doesn't work for more then the first transmit, even though the program doesn't halt.

    I can't help much with this issue as this is beyond my area of expertise (I'm mostly focused on tools (CCS) ). Kevin should be able to provide more insight.

    Thanks

    ki