• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 221 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.

IWR1843BOOST: IWR1843BOOST

Alan Milne
Intellectual 285 points
Part Number: IWR1843BOOST

Hi,

sorry if there's a different forum for this question, to do wit CCS, but It's an 1843 I'm using.

Three questions, all do do with debugging in CCS:

1)

When adding breakpoints, it seems I always have to do the extra step of "right-click & attach to context", even if there is only one processor in the project (e.g. in studio_CLI), or that code module is only used in one e.g. just MSS.  I assume this is basically to do with CCS's ability to debug multi-processor systems. Is there a setting to do this automatically?

2)

once I've done a debug run - and ready for changes, next step etc - it seems necessary to do a hard (power-off) reset before a ne debug session will start reliably (the code may start, but doesn't run properly).  Is there a setting in CCS to do a "more thorough" reset, so I don't have to power-off each time?

3)

As I have to do a power-off ... if I get the order wrong i.e. forget to stop the debug session before power down, CCS disables ALL the break points.  Can I stop it doing this?

many thanks

Alan Milne

  • 0
    TI__Mastermind 20831 points

    Hi Alan, 

    Alan Milne said:
    When adding breakpoints, it seems I always have to do the extra step of "right-click & attach to context",

    When are you setting the breakpoints? If you set the breakpoints after starting the debug session you shouldn't have to manually bind them each time. 

    Alan Milne said:
    Is there a setting in CCS to do a "more thorough" reset, so I don't have to power-off each time?

    The power cycle is required to reset the radar front end. I don't believe there is any way to do this via CCS setting but I will investigate. Alternatively, I believe you should still be  able to achieve the functionality that you are looking for if you send sensorStop CLI command then reset the CPU in CCS (Ctrl+Shift+R) then you should be able to load the code and run again without ending the debug session or power-cycling the device. 

    Best Regards,

    Josh

  • 0 in reply to Josh Dye
    Intellectual 285 points

    Hi Josh,

    great, many thanks!

    I thought the reset issue might be to do with the radar front end, if for no other reason than CCS doesn't have control of it, just MSS & DSS.  I assume that this would be per-processor, selected from the debug list, and is it the same as using the RESTART button in the tool ribbon?  I'll give this method a try, but there will cases where POR is necessary, depending on what I'm doing etc.

    I tend to "think and edit" and thereby set breakpoints in the CCS EDIT rather than DEBUG view, simply because there's more space to see more of the code - but that's because of how many windows I have open in the DEBUG view.  There's no accounting for how users use the tools!  I've tried setting breakpoints in DEBUG and can confirm this works - thanks.

    So, just the question of whether I can stop it disabling all breakpoints if I get the order wrong and remove power before stopping the debug session? I know this is definitely "user error" territory, but it would be nice if I could stop it happening.

    many thanks

    Alan

  • 0 in reply to Alan Milne
    TI__Mastermind 20831 points

    Hi Alan, 

    Sorry for the delay here. I've done some digging and unfortunately it seems there is no way to stop CCS from disabling the breakpoints if you disconnect the device before stopping the debug session. I can raise a ticket to see if this can be addressed in a future release but I can't say if/when that would happen.

    Best Regards,

    Josh 

  • 0 in reply to Josh Dye
    Intellectual 285 points

    Hi Josh,

    many thanks for trying!  Logging it as a possible future fix (or perhaps enhancement might be a better term) would be good - from a user's point of view.  Debugging sometimes needs sequences of break points to follow through what the code is doing, and to loose how they're set up can be troublesome.

    many thanks

    Alan