• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 82 subscribers
  • Views 11469 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Breakpoint Manager: Error enabling this function: This task cannot be accomplished with the existing AET resources.

GEOFF JACKSON
Expert 1535 points

I get this message "Breakpoint Manager: Error enabling this function: This task cannot be accomplished with the existing AET resources." when I try to set a breakpoint in CCS V6.1.0, and  I've never seen it before.

Can anyone tell me what it means and how to get round it ?

Thanks

  • 0
    Guru 192875 points
    Hi Geoff,

    Which debugger are you using? Also, check this thread: e2e.ti.com/.../60276

    Regards,
    Gautam
  • 0 in reply to Gautam Iyer
    Expert 1535 points

    Hi Guatam,

    I'm using the 28069M Launchpad, which is the XDS-100, isn't it ?

    What are "AET resources" ?

    Thanks,

    Geoff

  • 0 in reply to GEOFF JACKSON
    Guru 192875 points
    Did you try disconnecting the debugger & restarting CCS /PC ? Something similar: e2e.ti.com/.../207937
  • 0 in reply to Gautam Iyer
    Expert 1535 points
    Hi Gautam,

    I've got the breakpoints working in a limited way, but it will only allow two breakpoints to be set at the same time, and these are hardware breakpoints. Most of the program is running from flash memory as there is insufficient RAM.

    Is this what I should expect, only two hardware breakpoints, and no software breakpoints ? I used to have the same program running on the DRV8301-69M KIT and I don't ever remember seeing this limitation or error message before.

    Can you tell me what "AET" means ?

    Thanks,

    Geoff
  • 0 in reply to GEOFF JACKSON
    TI__Guru 57255 points

    Hi Geoff,

    Debugging a flash project requires the use of hardware breakpoints. 
    RAM projects can be debugged using only software breakpoints.  
    Hardware breakpoints are done by the MCU itself and therefore there is a maximum amount of them available, whereas software breakpoints are done by the IDE and are more-or-less limitless.

    As you've found, current C2000 devices only support 2 hardware breakpoints.  As a result, debugging a flash project with breakpoints could require a lot of enabling/disabling breakpoints.

    http://processors.wiki.ti.com/index.php/How_Do_Breakpoints_Work#Hardware_vs._Software_Breakpoints
    http://processors.wiki.ti.com/index.php/C2000_Flash_Common_Issues/FAQs#Using_Breakpoints_During_Debugging


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Expert 1535 points
    Hi Brett,

    Thanks for the advice which all makes sense.

    That's quite a limitation on debugging from flash, considering the problem of running a large program from RAM. Are there any plans to get round this, like more breakpoints or larger RAM ?

    Geoff
  • 0 in reply to GEOFF JACKSON
    TI__Guru 57255 points

    Hi Geoff,

    Breakpoints can be the most efficient way of debugging certain issues and having only 2 can be a limitation.

    In some situations, utilizing the real-time debug capability of the device can remove the need for hardware breakpoints.  It is a different approach to debugging, but is sometimes applicable.

    Outputting signals via GPIO outputs can also help during debug. 

    We are investigating and looking to increase the amount of hardware breakpoints available on future C2000 products.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Expert 1535 points

    Hi Brett,

    Thanks for the advice.

    I have another related problem/question; when I set a breakpoint in my main isr, the program never hits the breakpoint, wherever I put it.

    The interrupt is generated by an ADC read from a pwm trigger, and the isr is definitely being entered, so why no breakpoint ?

    Regards,

    Geoff

  • 0 in reply to GEOFF JACKSON
    TI__Guru 57255 points

    Geoff,

    Some thoughts:
    -Can you toggle a GPIO or change a variable inside the ISR to definitively prove that the CPU is entering the ISR?
    -Can you set breakpoints elsewhere? Do they work as expected?
    -Have you made code changes, but have not compiled/reloaded your program?  (when I run into what you're seeing, this is often my problem)


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Expert 1535 points
    Brett,

    Since I posted earlier I have found a bug in a routine which reads the SPI B port and which is called from the ISR; that is now working successfully. I just tried setting a breakpoint in the ISR and now it's hitting the breakpoint.

    I'm sure I recompiled and loaded before trying the ISR breakpoint earlier, so I've no idea why it has started working. Looks like the problem has gone away, but thanks anyway

    Regards,

    Geoff