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: generating hardware breakpoints

Tool/software: Code Composer Studio

Hello,

I'm trying to generate a hardware breakpoint (or any breakpoint) when the the memory location associated with a GPIO pin is written to.  Somewhere, somehow in my application,GP4P0 is being set high, when it doesn't appear my code is doing it.  I need to track down where that is occurring, so trying to set a breakpoint on any writes to that that GPIO bank.  Eventually, I'll need to narrow it down to just the LSB of bank 45, since that is GP4P0, but for now, I'd be happy just to be able to generate a breakpoint to any write to bank 45.

Here is a picture of the breakpoint setup, which seems like it should do as indicated, but yet now break of the processor occurs, even though I know there are explicit writes to bank 45.

What am I missing/doing wrong? Please advise,

Robert

  • Hi Robert,
    Based on your screenshot, I am assuming you are setting a watchpoint on some C6x device. Assuming the address (0x1e26064) is correct, the watchpoint does seem set up correctly (it should halt the CPU for any writes to that data address. I tried setting up a watchpoint on a C6x target with similar properties and it seemed to work ok. Did you try setting one to monitor a different address and see if watchpoints in general work on your device? Also, what device and CCS version are you using?

    Thanks
    ki
  • Thanks for the reply.  I tried doing it on a known variable that is being updated, and it didn't work there either.  In fact, after trying to do this HW watchpoint, on a write of that GPIO-related location, breakpoints don't work anymore at all.  When I use to double click on a line in firmware, it would put a solid ball next to it, in the margin to the left, and the code would run there and stop.  But now all double clicks on a line of code puts the blue bulb (light bulb?) with a line through it, as shown below.  And the code doesn't stop at that line.

    CCS is 7.3.0, for C6746

  • It looks like you may have inadvertently disabled all breakpoints. Check the breakpoint view and check the highlighted button as shown below:

     

    Thanks

    ki

  • Thanks.  After fixing that oversight, it looks like I'm breaking on the writes to the GPIO pin, as well.

    I actually need to break only under certain conditions, when GP4[0] is set high under unexpected conditions, so I'll need to make use of the GEL script to create the break condition.  So far, this appears to generate the break anytime GP4[0] is set high:

    ( ( *(unsigned int *)0x1e26064 & 0x1 ) == 0x1 )


    Robert

  • Does anyone see any flaw in this condition logic?  For some reason, it makes the system go nuts ... completely undefined processor behaviour

    ( ( ( *(unsigned int *)0x1e26064 & 0x1 ) == 0x1 ) && ( g_mb_debug == 1  ) )

    g_mb_debug is a global unsigned int ... just a condition indicator I prep internally in the code, where I want the break to occur, if the GPIO pin is set high (which is the first part of the logical AND statement above).  If I remove the second part of it, things work fine ... but I need that second half discrimination to make the break/watchpoint useful.

    Robert

  • This original question was answered, and my follow-up is different enough that I created a new thread here:

  • Thank you Robert. We always encourage a new thread for a new topic so I appreciate you creating a new thread.