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.

Resume when debugging does not seem to work

I am using CCS v5 to develop and debug a Stellaris microcontroller (LM4F232H5QD), and sometimes it appears that the "Resume" function is not working. Typically I'm setting a breakpoint inside some repeating piece of code, like a for loop, and I want to resume until the breakpoint hits again next time around. The problem that I am experiencing is that it never seems to run the loop again, it just stops immediately when I click resume. For example; I am watching some counter variable, and when I click resume a few times I expect it to increase, but it stays at the same value. What I have to do in this case is to manually single-step over the code that increases the counter variable, and then click resume. Any ideas what could be wrong?

  • Hi Pelle,

    one of the only differences I can think of is that in step over mode the default setting is usually to turn off interrupts.  Do you think there is an interrupt generating this behaviour?  What emulator are you using?   Would you be willing to share (offline of course in a conversation or friend request) you project?

    Best Regards,
    Lisa

  • Hi Lisa,

    At this moment I cannot share my complete source code for confidentiality reasons, but I have discovered a new (but similar) problem which may be able to provide more information. If I have the time I can try to create new simple project and see if it suffers from the same problems. Anyway, the problem I discovered yesterday:

    I single step through my interrupt handler, and it works fine until I reach an if-statement. In the if-statement I simply compare a boolean value. If I step OVER the if, the mode in the debugger changes to "running" and no more interrupts happen. If I suspend and set a new breakpoint in either the same or another interrupt handler, it never stops again when I resume. I have tried setting a breakpoint on the line after the if-statement, (which contains a switch-case), and it will stop there, but if I single step again it resumes and no more interrupts occur. However, if I set the breakpoint inside one of the case: labels in the switch, it stops there, I can resume, and it will break again on the next interrupt. Very strange behavior. I have inspected the registers when this happens, and from them it appears as if it should keep on getting interrupts. The ISR in which this happens is an ADC conversion triggered by PWM, and the interrupt occurs after the uDMA controller has transferred the ADC data. I can see that the ADC interrupt is enabled in the NVIC, it has a raw interrupt pending (ADC_RIS), and in the CHIS register of the uDMA I can see that it has a transfer complete interrupt pending. Is there anything else I can check? Any other ideas?

  • HI Pelle,

    ok, let me see if I can get a bit of help from some more expert colleagues here.

    In the mean time what if you try the following debug settings.  Under Project->Properties->Debug ...

    On the right you should have Generic Debugger Options.

    What if you scroll down and deselect

    "Automatically step over functions without debug information when source steping"

    Also deselect, under the "Disable Interrupts" section

    "when source stepping"

    Please keep me informed and as soon as we have further feedback/thoughts we will let you know.

    Best Regards,
    Lisa

  • Lisa TI said:

    "Automatically step over functions without debug information when source steping"

    I tried this, but unfortunately it did not make any difference.

    Lisa TI said:

    Also deselect, under the "Disable Interrupts" section

    "when source stepping"

    If I do this I get thrown into another interrupt handler as soon as I make a single step forward, since continuously receive I2C and UART RX interrupts.

    Right now this isn't a huge problem for me, but if you come up with any other ideas I'll gladly try them out.

  • Hi Pelle,

    ok, thanks for your feedback.  Glad to hear that at least this is something you can work around.

    No, we unfortunately don't have many further ideas.  One might be to check for a port conflict or something that could be disrupting the debugger but that is about the only further thing.


    All the best with development.

    Best Regards,

    Lisa