Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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

Using the DSS interface in CCS to write a script to realize the automated test process, when the run method is called to run, an error timeout is reported and an exception is thrown.

rui.zhu
Prodigy 50 points
Other Parts Discussed in Thread: AWR1843

Hello，

I use AWR1843, XSD110 debugger and ccs software to build a debugging environment, and use python to write scripts to call the methods in the DSS interface to achieve automated testing. When the target board is running, the script execution shows a timeout and throws an exception, but when the CCS software is used for manual operation, the development board can run successfully. The script execution content is the same as the manual operation process. I want to know what causes this error timeout? Please help everyone, thank you！The screenshot of the error report and the content of the script are as follows：

python_script (1).pdf

  • 0
    TI__Guru**** 439851 points

    Hello,

    rui.zhu said:
    . I want to know what causes this error timeout?

    Your script sets a timeout of 15 seconds.

    The target.run API is a blocking call that will remain blocked until the target is halted. If this API does not return in 15 seconds, then the timeout will be triggered and an exception will occur. You can choose to handle the exception to avoid script termination, or if you do not wish to timeout, you can simply remove the call the sets a timeout value.

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 50 points

    Hello ki, thank you for your reply, this script is rewritten according to the example given by the ccs official debugging tutorial. You mean, we have two choices, either handle the exception it throws or cancel the timeout setting, right? Manually operate on the ccs software as normal, click "resume" after the two kernels are loaded, and the red and green indicators of the AWR1843 development board will flash alternately. In addition, if we add a breakpoint in the script, the program does not seem to stop at the breakpoint. If the script is executed, the development board cannot run successfully. Also, I want to ask the function of the button "resume" of ccs software is equivalent with target.run API?

  • +1 in reply to rui.zhu
    TI__Guru**** 439851 points
    rui.zhu said:
    You mean, we have two choices, either handle the exception it throws or cancel the timeout setting, right?

    Other options are to increase the timeout value (which would only be helpful if you expect the target to eventually halt on its own) or to use runAsynch (which is a non-blocking API).

    rui.zhu said:
    In addition, if we add a breakpoint in the script, the program does not seem to stop at the breakpoint. If the script is executed, the development board cannot run successfully.

    In your screenshot, I see you created a group and did a synchronous run. See section 7.6.9 of the CCS User's Guide for an example of a synchronous (simultaneous) run:

    https://software-dl.ti.com/ccs/esd/documents/users_guide/sdto_dss_handbook.html#multiple-debug-sessions-for-multi-core-debug

    I assume when doing the same steps manually via CCS IDE, the breakpoint is successfully reached?

    rui.zhu said:
    Also, I want to ask the function of the button "resume" of ccs software is equivalent with target.run API?

    Either the run or runAsynch API would be the same as "resume". Perhaps "runAsynch" would be the most equivalent since that API call is not blocking - similar to if you pressed the "resume" button in the CCS IDE. However, a blocking call is typically more used for automation..

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 50 points

    Thanks a lot Ki, the problem is solved.

  • 0 in reply to Ki
    Prodigy 50 points

    Hello ki, there is another question I want to ask you, we can use the script to achieve the successful operation of the target board, and can stop at the breakpoint, but at the breakpoint, we want the target board to continue running and run to the next breakpoint to stop or stop at the breakpoint again, and then calculate the running time of the code between the two breakpoints. How should this be done? I checked the API documentation, and it seems that there is no interface that can be called to make it run again. In this case, I can only re-power on the target board, execute the script again, and make the target board run? We want it to continue execution after the first stop at the breakpoint instead of starting over. Thanks!

    Rui

  • 0 in reply to rui.zhu
    TI__Guru**** 439851 points
    rui.zhu said:
    but at the breakpoint, we want the target board to continue running and run to the next breakpoint to stop or stop at the breakpoint again, and then calculate the running time of the code between the two breakpoints. How should this be done?

    After the first breakpoint, call the clock.runBenchmark API. This will run to the next breakpoint and return the cycle count:

    For further questions, if they are unrelated to the previous question please start a new thread. This makes it easier for other users who have the same question since many just look at the thread title. Hence we prefer one thread per question type.

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 50 points

    ok thanks ki, I will restart a new thread.