• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 884 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.

Target halts when debug server session terminates, depends on "AddCEXITbreakpointAfterLoad" option

Anthony F. Seely
Guru 68920 points
Other Parts Discussed in Thread: TMS570LS3137

I am launching loadti with the -a option for asynchronous run.

From a normal code composer IDE session, if I 'Run' my target with this test code and then terminate the debug session, I can see that the target is still running. (LED still blinking).

But, from debug server the code is started with the 'runAsync' method,  and it runs for a while (because the LED blinky counter has counted up a lot..) but then is halted when the session terminates.    I connected to a board in this state with CCS and no gel to see where it was and found it in that blinkly loop with the counter pretty far along.

I made a copy of loadti to hack into and I found that adding this:

                        debugSession.options.setBoolean("AddCEXITbreakpointAfterLoad", false);

Before the run async

                        debugSession.target.runAsynch();

command 'fixes' the issue.  (The default is 'true' for AddCEXITbreakpointAfterLoad).


I've tried a few times changing the script from true to false and whenever that option is true, the target halts after the DSS script exits.

Whenever it's false, the target continues running (desired behavior).

I don't think this is correct behavior though, because the program's main function never returns; yet the program halts when the option is set.

The target is a Cortex R4F  (TMS570LS3137).

Any guidance would be appreciated, if this needs to be reported on a CQ I'll do that if you tell me.

  • 0
    TI__Guru**** 463871 points

    Great work Anthony. I agree, why a BP at the exit point makes a difference (when that point should never be reached) is beyond me. If you don't mind filing a CQ, that would be great.

    Thanks

    ki

  • 0 in reply to Ki
    TI__Guru 68920 points

    Hi Ki,

    I'll file a CQ now. 

    Do you think it's worth discussing the addition of command line options for the standard 'loadti' utility to allow 'non-default' settings for any of the DSS options?

    I think if we had this, then we could use the standard loadti utility without having to make a hacked up derivative of it.

    I wound up setting two different options by hacking into loadti:

      added:
       debugSession.options.setBoolean("AddCEXITbreakpointAfterLoad", false);
       before the call to debugSession.target.runAsynch() in main.js.
       without this, the TMS570 target is halted when the dss session terminates
       and then the matlab PIL host side times out.

      added
       debugSession.options.setString('FlashEraseSelection',
                'Necessary Sectors Only (for Program Load)');
       before the call to debugSession.memory.loadProgram to speed flash download

    I'm thinking it might be a cool idea to be able to pass these as parameter, value pairs on the command line though.

    Maybe  like   --option 'FlashEraseSelection' 'Necessary Sectors Only (for Program Load)' ??

    What do you think and if it's a good idea who should we talk to?

    Thanks and Best Regards,

    Anthony

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

    Hi Anthony,

    Anthony F. Seely said:
    I think if we had this, then we could use the standard loadti utility without having to make a hacked up derivative of it.

    Note that the original intent of loadti is to provide a DSS example that highlights DSS and is useful out of the box. We actually encourage people to take it and modify/hack it to add additional functionality. 

    That said - we will add functionality ourselves if the functionality can benefit a wide audience. And changing the debugger/flash options certainly would do so. Perhaps an option to pass in debugger and flash options would be a good one to add. An option to spit out the options and another set to apply them. I'll CQ this one in.

    Thanks

    ki

  • 0 in reply to Ki
    TI__Guru 68920 points

    Hi Ki,

    On the first issue the CQ is SDSCM00045933

    Best Regards,

    Anthony