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 breaks random / unwanted

Hello,

since a few days a unwanted behavior occurs while using CCS ( 6.0.1.00040 )

We use a F28M35H52C1 at the TMDSDOCKH52C1 Kit and program the M3 CPU in C. We don't use BIOS / RTOS. C28 CPU doesn't play a role at the moment.

Now we have the problem that the debugger break at a random point in the program and we have to set continue for further execution. When this point is reached again, it will come to a new break. As long the code isn't changed it will always break at the same code point, also when the CPU is new programmed.

When changing the code (e.g. adding a new  function) the debugger breaks at new random point or don't break (since there are so many functions not every one is tested, so this can't be say for sure).

The break point isn't always on the same code address (at the moment it is 0x0022C3A4 but it has also been 0x0022A2C8)

In CCS there are no breakpoints set.

When using the device without CCS it runs normal.

Hopefully someone has a hint for us.

Best regards


Mathias

  • Hi Mathias,
    I wonder if there some hidden breakpoint exists. Can you provide of screenshot of CCS when the unintended halt occurs? I'm most interested in the contents of the Debug view and the Disassembly view when the halt occurs.

    Thanks
    ki
  • Mathias Meier said:

    since a few days a unwanted behavior occurs while using CCS ( 6.0.1.00040 )

    I take it that it was a change in the code that triggered this behavior to start happening. Is that correct?

    At what point in the code is it always halting? Within a ISR? Have you looked at the disassembly view in CCS when the code is halted to determine what instructions are around that address? Could there be a software breakpoint instruction embedded in the code causing a halt?

    Normally without a breakpoint set (either from within the code or from CCS) the code should not be halting, so it is difficult for us to tell what could be happening here without more insight into the code or a test project that demonstrates the behavior.

  • Hello,

    so as always, in the moment the post was written, the behavior stopped until today.

    So here is the picture:

    Yes every time we change the code the behavior can occur on a completely different code section. In the picture CCS stops in the dhcp library every few moments until the device has become a IP.

    After the next code change it may occur on a different function and code section (so it isn't always at 0x22e3d8).

    As far as we can see no breakpoint are set, we tries also the option 'Skip all breakpoints' without success.


    Best regards

    Mathias

  • Mathias,
    Are you able to share your project with us so we can try to duplicate the issue? Being able to reproduce the behavior will greatly help in analyzing the issue further.
  • I'm having a similar issue. Anyone have suggestions?
  • Hmm, just tried a bunch of stuff that didn't work:
    - restarting CSS
    - deleting and recreating the debug configuration
    - deleting and recreating the workspace

    But power-cycling the target appeared to fix the issue.
  • Matt - it could be that you had some embedded (sw) breakpoints set on the target which the debugger lost track of (so it didn't display them). A power-cycle would have flushed those breakpoints out.

    ki
  • Are the SW breakpoints written to flash?

    I would have thought that a program reload would have removed any software breakpoints.