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.

Issues with Loadti in Cantata build

Other Parts Discussed in Thread: TMS320F28335

Hi,

We are trying to integrate Cantata into CCSv5.3.0.

We are using loadti to get code onto the target (TMS320F28335) to execute the tests generated. The file seems to run and produce an output but then the program stalls.

Looking at the main.js file for loadti we get to the point where we would expect to see a NORMAL COMPLETION: <x> cycles output after the output comes back from the target but we don't see this in the console window.

We think that the procedure is getting stuck somewhere in the loadti but we aren't sure where. Does anyone have any experience of the loadti utility and might have an explanation as to why it is getting stuck.

It seems to be getting stuck at the

var cycles = debugSession.clock.runBenchmark();

command in main.js.

Kind regards,

Adam

  • Hi Adam,

    Adam Ardron said:

    It seems to be getting stuck at the

    var cycles = debugSession.clock.runBenchmark();

    This is the main call to run the application until it reaches a breakpoint (like one at the exit point of your program). Does your program have an exit point that is supposed to be reached? And if so, did you explicitly disable setting a breakpoint at it?

    Thanks

    ki

  • Hi Ki,

    Thanks for your response. Would a breakpoint be added automatically or would it have to added manually? Breakpoints have not been explicitly disabled.

    The program ends with a return statement. A call to exit(); has also been tried.

    There is only skeletal debug information for the application at present as we are not using any debug compile options.

    Also I have tried a very simple program which fine in the debugger in CCS but when run with loadti fails to exit in the same manner as described before.

    Thanks and regards,

    Adam

  • What i mean by exit point is basically does your program reach the C$$EXIT label in the abort() routine.

    You can check this by running your program in CCS and see if it self terminates at that location

    Thanks

    ki

  • Ki,

    Thanks for your response. If I debug a simple application ("Hello World") and hit play in the debug mode then I get the output in the console. However I do not see the call to abort. If I then hit the pause button I see the abort() function.

    Is there something I am missing to get to the abort function?

    Adam

  • Adam Ardron said:
    However I do not see the call to abort. If I then hit the pause button I see the abort() function.

    Sounds like the debugger is not placing a breakpoint at the exit point. This is probably intentional to avoid using up a breakpoint resource on targets with limited hardware breakpoints (since majority of code tends to be in flash).

    It is the same scenario as described here for MSP430:

    http://processors.wiki.ti.com/index.php/Loadti#Using_loadti_with_MSP430

    Your solutions are the same also.

    Thanks

    ki

  • Hi Ki,

    Thanks for your help. Solved this by explicitly adding a breakpoint in main.js of loadti. The program now runs to completion.

    However I now get a message in the console:

    SEVERE: C28xx: Error programming AET Job: This task cannot be accomplished with the existing AET resources.

    Don't know if this is a problem. I will look into it.

    Thanks and regards,

    Adam

  • Hi Adam,

    Most likely you are just running into issues with lack of AET resources. loadti is trying to do something that requires another resource. I believe you only have 2 for your device. Things that take up an AET resource are hardware breakpoints, watchpoints, single stepping, running and so forth. Because you explicitly set another breakpoint, you used up another AET resource. You may being using up too many now. CCS tends to set breakpoints at main and uses them for C I/O. You can try explicitly disabling them via the debugger options. If everything is running ok, then you can disregard the warning.

    Thanks

    ki