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.

CCSTUDIO3: Breakpoints intermittent

Part Number: CCSTUDIO3


Lately my breakpoints are often skipped.

It may be that they are in code with different load and run addresses. But they often work in the relocated code.

I am getting an illegal operation error several layers deep and I need to set the breakpoint close to that point. I cannot single step through the layers or I will miss communications with another device. Also it breaks hard so reset/restart/go does not work. Flash must be reloaded.

Any ideas?

Thanks,

John

  • John,

    Please take a look at this thread on same topic. Please go through the thread, it should resolve your breakpoint issue.

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/908898/ccs-tms320f28379d-break-point-problem

    Regards, Santosh

  • Thanks for posting.

    First, is there a way to force a breakpoint to be SW instead of HW? I did not see anything in properties. It is not a big deal as one can set 2 throwaway breakpoints in main() and thus the next must be SW.

    My first 2 breakpoints are in flash locations and they work. Then I have several in ram that do not work. I rebuilt the project and waited until the debugger stopped loading and was positioned at the beginning of main. At this point I created my ram breakpoints. They are both ignored.

    The code where the breakpoints do not work have different load and run addresses. The code is not copied at the beginning in Device_init(), but conditionally loaded later. It is being copied when needed as I can single step or run to cursor in those areas. After the copy I can poke along like a poxxed hedge creeper and set software breakpoints in the same function as I go and they work. Sometimes maybe a fn call or 2 deeper.

    So I have had to find a workaround. I came up with a set of functions like this that are in the same file as main() which is in flash. So in sort of a callback fashion, in my ram functions that ignore breakpoints I insert calls to functions like the one below and I can set and disable a breakpoint in these as needed.

    void bp1()
    {
        GPIO_writePin(myGPIO15, 0);     // A line the !@#$%&* optimizer won't delete.
    }

    John

  • John,

    Did you check the map file, what is the address for bp1() function?

  • I did not check the address of bp() since it was reachable from everywhere. I use it as a workaround because other breakpoints do not work.

  • John,

    Can you check to see where is this pointing to?

    Are you saying that it works when you use this function bp() but it does not work when you are calling directly?

  • I will try to explain more clearly.

    My main() runs in flash and it calls a function to get a user selection. When the user makes a selection that piece of code is copied from flash to memory and then executed.

    Breakpoints in main and other functions in flash seem to work. Breakpoints for the code that has different load and run addresses do not usually work. I put the little function bp in the same file as main() so it would be in flash. The relocated code can find the bp function and call it. So I tried putting a breakpoint in bp(). Since bp() is in flash, next to main() the breakpoint in bp() works.

    Some additional information. Once the code in ram starts running the command "Run to Line" works. If I start single stepping through the ram code sometimes I can set a breakpoint further ahead in the same function and it will work.

    So I use bp() to allow me to see how far I am getting in my code before it crashes. Actually I ended creating several functions like it, bp1(), bp2(), bpEnd(), etc that are called from the ram functions I am debugging. But it is an awkward workaround as building and loading code takes so long.

    Thanks,

    John

  • John,

    I am looking into it and will get back to you by Monday.

    Regards, Santosh

  • John,

    I did not get a chance to look at it. Just checking with you, if you have resolved the issue?

    Regards, Santosh