• Locked Locked
  • Replies 2 replies
  • Subscribers 52 subscribers
  • Views 607 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.

Minor bug in breakpoints view on CCS6.0.0.00040 (TMS570LS0432)

Robert Cowsill
Guru 16361 points
Other Parts Discussed in Thread: TMS570LS0432

When starting a new debug session, CCS can be set up to restore the breakpoints from the previous debug session.

When this is done on TMS570LS0432 (and possibly other ARM targets), the restored breakpoints are incorrectly displayed in the breakpoints view. The view shows them to be software breakpoints when they are in fact hardware breakpoints.

Repro steps:

  1. Ensure preferences allow breakpoints to be restored from previous debug session when starting a new one
  2. Disable all preferences that require setting a breakpoint (eg CIO, semihosting...)
  3. Delete all breakpoints from the breakpoints view (in edit perspective)
  4. Start a debug session on a TMS570LS0432 target
  5. Set six breakpoints in the source
  6. Check breakpoints view - notice all breakpoints are listed as [H/W]
  7. End debug session
  8. Start new debug session
  9. Check breakpoints view - now all breakpoints are listed as [S/W]
  10. Try to add another breakpoint
  11. Observe warning about insufficienct AET resources, confirming that six hardware breakpoints are already set.
  • TI__Guru**** 468201 points

    Hi Robert,

    I assume at step 5, you are setting these breakpoints in Flash, hence they are HW breakpoints

    I assume between steps 8 and 9, the target has been connected and your program loaded.

    When you are at step 9, are the breakpoints enabled? When I reproduce your steps, I see them all as HW breakpoints but they are all disabled (which i wasn't expecting).

  • in reply to Ki
    Guru 16361 points

    Ki-Soo Lee said:

    I assume at step 5, you are setting these breakpoints in Flash, hence they are HW breakpoints

    I assume between steps 8 and 9, the target has been connected and your program loaded.

    Correct

    Ki-Soo Lee said:
    When you are at step 9, are the breakpoints enabled? When I reproduce your steps, I see them all as HW breakpoints but they are all disabled (which i wasn't expecting).

    Yes, I was getting enabled breakpoints which are shown as software breakpoints (but obviously can't be as the code is in flash).

    Looking closer, the behaviour differs depeding on whether I set the original breakpoints (step 5) on source code lines or the corresponding disassembled opcode(s). Breakpoints originally placed on source code lines (even in the disassembly view) are shown as software breakpoints when restored. Breakpoints on the disassembled opcodes are shown as hardware breakpoints.

    EDIT: Here are some screenshots of the setup and results. The first is showing step 6 after setting the hardware breakpoints. I added one at line 24 in the source view and one at line 26 in the disassembly view (on a source code line between the disassembled opcodes). The third breakpoint was placed in the disassembly view on the opcode at address 0000000c:

    Next I terminated and restarted the debug session. Here's a screenshot during the launch process (at step 8), while the flash is being erased:

    Notice how the breakpoints at lines 24 and 26 are now disabled software breakpoints, but the breakpoint at 0000000c is an enabled hardware breakpoint. I'm not sure if this is relevant, but it does show the point at which the source breakpoints change their displayed type from H/W to S/W.

    The next image shows the situation once flash has been cleared and the firmware uploaded at step 9: