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.

Hardware breakpoint usage in CCS v4 for F28x

The number of hardware breakpoints available in CCS v4 appears to be different than CCS 3.3 for F28x devices . This is related to this external post: http://e2e.ti.com/support/development_tools/f/81/p/3147/10875.aspx#10875

Basically F28x devices have 2 hardware breakpoints when debugging in Flash.

In CCS 3.3, my understanding is that a user can set 2 HW BPs at a time. If the Profiler Clock is enabled, it appears only 1 BP can be set because the Profiler uses up 1 analysis unit.

For BIOS programs, with Profiler Clock disabled, I can set 2 BPs and run to both. However, once the BIOS RTA or other BIOS window is opened, only 1 BP can be set after that. Even closing the BIOS windows after that still allows only  1 BP. So it appears that BIOS is using up one analysis unit as well.

In CCS v4, for non-BIOS programs I see behavior similar to CCS 3.3. For BIOS programs though, I can only set 1 BP. Attempting to set a 2nd BP results in a message "Trouble Setting Breakpoint with the Action "Remain Halted" ....". So it looks like a resource is always being used by BIOS even when no BIOS window is open. Can someone confirm is this is the case and if something can be done to disable that BP to allow the user to be able to set 2 BPs?

In this customer's case they don't need to do any BIOS debugging, so if there was a way to turn off BIOS RTA/KOV and recover that breakpoint that would be great.

  • Aarti,

    Are you using DSP/BIOS 5.x release? If so, you can try to recover the BP by disabling RTA analysis and using non-instrumented DSP/BIOS libraries. I just got a F2808 board and will test myself...

    I'll get back soon.

    Cheers,

    Rafael

     

     

     

  • Aarti,

    I tried a number of approaches to free the Breakpoints when using BIOS and CCSv4 without success. This might well be a bug. Couuld you file it and send me the number?

    I used the SPRA958 examples as a test case, since they work perfectly to compare between BIOS/non-BIOS code written to Flash (where HW Breakpoints are a must).

    Thank you,

    Rafael

  • I submitted this as SDSCM00034620.

    Thanks
    Aarti

  • From Karl Wechsler:

    I bet the problem is more specific and relates to the app being an "RTDX" app, not a "BIOS" app.
     
    If so, a possible workaround would be to disable RTDX from the BIOS app.

    The attached slide shows how to disable RTDX.  First change the HST link type to "NONE", then uncheck the RTDX box.
    ----------------
    Confirmed that the above workaround does restore the usage of that breakpoint.

    However the following usability issues remain:
    - no easy option in Debugger Properties to disable RTDX support if enabled in the program
    - no clear message that the breakpoint resource is in use by RTDX and how to disable it
    disable-RTDX.ppt