• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 1898 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.

Setting software breakpoints on TMS570LS0432 in CCS6

Robert Cowsill
Guru 16361 points

Other Parts Discussed in Thread: TMS570LS0432

Is it possible to set software breakpoints in the CCS6 debugger when attached to a TMS570LS0432 (Hercules launchpad)?

On MSP430 if you try to add another breakpoint when all the hardware breakpoints are in use, then CCS will use a software breakpoint instead.

This doesn't appear to be the case for TMS570LS0432. Using up all the AET resources just gives an error message and adds a disabled H/W breakpoint.

I have "Debug->Misc->Allow software breakpoints to be used" enabled in the project properties.

I've also tried disabling CIO function use, semihosting, halt on termination and auto run to main to free up their breakpoint resources. That lets me set all six hardware breakpoints, but still gives the error message when I try to add a seventh.

I'm using CCS6.0.1.00040.

  • 0
    TI__Guru**** 481381 points

    Hi Robert,

    If the debugger memory map is enabled and specifies the address you are trying to set a breakpoint on as "read-only", the debugger will always try to set a HW breakpoint since you will not be able to set a SW breakpoint there. Check the debugger memory map to confirm

    Thanks

    ki

  • 0 in reply to Ki
    Guru 16361 points

    Thanks Ki, I'll give that a try later.

    Out of interest, could that also explain why the "Breakpoint" and "Hardware Breakpoint" options in the context menu under "Breakpoint (Code Composer Studio)" do the same thing?

    The reason I ask is that this also occurs when debugging MSP430, even though CCS does let me add software breakpoints on that platform (once the HW ones are all used up).

  • 0 in reply to Robert Cowsill
    TI__Guru**** 481381 points

    Robert Cowsill said:
    Out of interest, could that also explain why the "Breakpoint" and "Hardware Breakpoint" options in the context menu under "Breakpoint (Code Composer Studio)" do the same thing?

    "Breakpoint" will try to set a software breakpoint while "Hardware Breakpoint" will try to set a hardware breakpoint. The reason why you would see the same behavior is because the debugger memory map has that address as read-only so when trying to apply a software breakpoint, the debugger will automatically use a hardware breakpoint instead for you. If the debugger memory map was not enabled, you'd see an error message saying that it tried to set a software breakpoint but it failed because it is read-only memory and it will now try a hardware breakpoint.

    Robert Cowsill said:
    The reason I ask is that this also occurs when debugging MSP430, even though CCS does let me add software breakpoints on that platform (once the HW ones are all used up).

    MSP430 is the only device where we allow software breakpoints to be used for read-only memory (it will actually flash the halt opcode into that address). Other devices (like ARM) does not have this capability so you can only use hardware breakpoints. This is the difference you are seeing.

    Thanks

    ki

  • 0 in reply to Ki
    Guru 16361 points

    Ki-Soo Lee said:
    MSP430 is the only device where we allow software breakpoints to be used for read-only memory (it will actually flash the halt opcode into that address). Other devices (like ARM) does not have this capability so you can only use hardware breakpoints. This is the difference you are seeing.

    Now I've had chance to look at the Memory Map in the debugger I see what you mean. MSP430 lists the whole address space as RAM. TMS570LS0432 lists the flash address range as ROM, indicating that it's impossible to set software breakpoints on code in flash from the debugger at runtime.

    Ki-Soo Lee said:
    Other devices (like ARM) does not have this capability so you can only use hardware breakpoints.

    Just for clarity, is the debugger prevented from modifying flash at runtime by the memory map settings, or is it actually a hardware limitation? In other words, would I be wasting my time editing the GEL file (I expect so).

    Ki-Soo Lee said:
    "Breakpoint" will try to set a software breakpoint while "Hardware Breakpoint" will try to set a hardware breakpoint.

    Ok, so I now understand why the debugger will fail to set a software breakpoint and falls back to using a hardware breakpoint on TMS570LS0432. What I'm still not clear on is why the same thing happens with MSP430.

    If I start an MSP430 debug session and have no breakpoints set, using "Breakpoint" creates a hardware breakpoint. It's only when the hardware breakpoints are used up that the debugger starts to use software breakpoints instead. The two context menu options do the exact same thing; first try to set a hardware breakpoint, then if that fails try setting a software breakpoint instead.

  • 0 in reply to Robert Cowsill
    TI__Guru 69070 points

    Robert,

    Which MSP430 part?

    The TMS570LS0432 device has FLASH memory.  You can't in general write to flash memory without first erasing the entire sector.    There is actually a company that has an 'unlimited flash breakpoint' capability and you can guess how this is accomplished - you would have to upload the entire sector,  erase the sector, and write back the whole sector...

    If your MSP430 part is FRAM based (a different nonvolatile technology) the rules might be different than flash and that might explain the different setting.   This is just speculation - you should confirm w. someone from the MSP430 team.

  • 0 in reply to Robert Cowsill
    TI__Guru**** 481381 points

    Robert Cowsill said:
    Now I've had chance to look at the Memory Map in the debugger I see what you mean. MSP430 lists the whole address space as RAM. TMS570LS0432 lists the flash address range as ROM, indicating that it's impossible to set software breakpoints on code in flash from the debugger at runtime.

    Well that is part of the answer. You simply cannot use software breakpoints in Flash on non-MSP430 devices. It is not supported, even if you disabled the debugger memory map on the TMS570LS0432. The debugger will try to set a software breakpoint and fail.

    Robert Cowsill said:
    Just for clarity, is the debugger prevented from modifying flash at runtime by the memory map settings, or is it actually a hardware limitation? In other words, would I be wasting my time editing the GEL file (I expect so).

    For the TMS570LS0432, the answer is both. The memory map would normally block write access if the debugger memory map specifies that memory region as read-only. It is also a hardware and debugger limitation where software breakpoints are not supported in Flash.

    Robert Cowsill said:
    Ok, so I now understand why the debugger will fail to set a software breakpoint and falls back to using a hardware breakpoint on TMS570LS0432. What I'm still not clear on is why the same thing happens with MSP430.

    It's because that debug capability for using a software breakpoint in Flash on the TMS570LS0432 is not supported. It is supported just on MSP430 devices as far as I know.

  • 0 in reply to Anthony F. Seely
    TI__Guru**** 481381 points

    Anthony

    Anthony F. Seely said:

    If your MSP430 part is FRAM based (a different nonvolatile technology) the rules might be different than flash and that might explain the different setting.   This is just speculation - you should confirm w. someone from the MSP430 team.

    As far as I know, this is supported on all MSP430 devices. I remember trying this (using SW breakpoints in Flash) on a Flash-based MSP430 devices.

  • 0 in reply to Ki
    Guru 16361 points

    Ok, I'm happy to call this one answered as far as the TMS570LS0432 is concerned.

    To minimise confusion I've started a new thread for my remaining question about MSP430 breakpoints.