Tracing: Difference between revisions
No edit summary |
No edit summary |
||
| Line 5: | Line 5: | ||
stride --device=TCP:localhost:8000 --database=%STRIDE_DIR%\sdk\windows\out\testapp.sidb --trace | stride --device=TCP:localhost:8000 --database=%STRIDE_DIR%\sdk\windows\out\testapp.sidb --trace | ||
This will cause the runner to listen indefinitely for test point and log messages from the target device. When the runner is passively tracing like this, you can terminate the runner by entering '''<tt>ctrl-c</tt>''' in the console window. This mode of tracing works | This will cause the runner to listen indefinitely for test point and log messages from the target device. When the runner is passively tracing like this, you can terminate the runner by entering '''<tt>ctrl-c</tt>''' in the console window. This mode of tracing works well if your device under test is continuously executing the instrumented code '''or''' if you can manually start the processing on the device (via external input, for example). | ||
If, however, the source code under test must be initiated by a remote function call (using [[Scl_Function|STRIDE remoting]], then you will need to incorporate the function call into the execution of the runner. The simplest way to accomplish this is to write a simple script like this: | |||
'''perl example:''' | '''perl example:''' | ||
<source lang="perl"> | <source lang="perl"> | ||
| Line 15: | Line 16: | ||
change the ''MyRemoteFunction'' name to match your function name(s). Other functions calls can be added to the script if more than one function call is required to start your processing. | change the ''MyRemoteFunction'' name to match your function name(s). Other functions calls can be added to the script if more than one function call is required to start your processing. | ||
Once you have written this simple script to invoke your function(s), you can | Once you have written this simple script to invoke your function(s), you can execute it with the runner using: | ||
stride --device=TCP:localhost:8000 --database=%STRIDE_DIR%\sdk\windows\out\testapp.sidb --trace --run=MyFunctionCall.pl | stride --device=TCP:localhost:8000 --database=%STRIDE_DIR%\sdk\windows\out\testapp.sidb --trace --run=MyFunctionCall.pl | ||
| Line 41: | Line 42: | ||
</pre> | </pre> | ||
As you can see, any test points or logs that are executed in the source under test will be reported to the console output. This provides a mean to peruse the output of your instrumented source code and do a quick sanity check of your instrumentation. | |||
Tracing within the runner also allows filters to be applied and timeout intervals to be specified - more details can be found in the [[STRIDE Runner]] page. | |||
Revision as of 05:43, 11 February 2010
Once you have instrumented your source code, you might want to verify that STRIDE Test Points are indeed being reported as you expect. One easy way to accomplish this is by using the console trace output feature in the STRIDE Runner.
The simplest usage model for tracing with the runner is to add the --trace flag to your command line runner parameters, for example:
stride --device=TCP:localhost:8000 --database=%STRIDE_DIR%\sdk\windows\out\testapp.sidb --trace
This will cause the runner to listen indefinitely for test point and log messages from the target device. When the runner is passively tracing like this, you can terminate the runner by entering ctrl-c in the console window. This mode of tracing works well if your device under test is continuously executing the instrumented code or if you can manually start the processing on the device (via external input, for example).
If, however, the source code under test must be initiated by a remote function call (using STRIDE remoting, then you will need to incorporate the function call into the execution of the runner. The simplest way to accomplish this is to write a simple script like this:
perl example:
use STRIDE;
$STRIDE::Functions->MyRemoteFunction();
change the MyRemoteFunction name to match your function name(s). Other functions calls can be added to the script if more than one function call is required to start your processing.
Once you have written this simple script to invoke your function(s), you can execute it with the runner using:
stride --device=TCP:localhost:8000 --database=%STRIDE_DIR%\sdk\windows\out\testapp.sidb --trace --run=MyFunctionCall.pl
(assuming you named your script MyFunctionCall.pl)
Once you have managed to start the source under test on the device and have connected with the runner, you should see output that looks roughly like:
Loading database...
Connecting to device...
Executing...
script "c:\s2\MyFunctionCall.pl"
2082576600 POINT "START" [../sample_src/s2_expectations_source.c:62]
2082586700 POINT "IDLE" - 02 00 00 00 [../sample_src/s2_expectations_source.c:77]
2082596700 LOG "Info" - Idle state entered first time [../sample_src/s2_expectations_source.c:85]
2082596701 POINT "ACTIVE" - 03 00 00 00 [../sample_src/s2_expectations_source.c:100]
2082606800 POINT "ACTIVE Previous State" - IDLE [../sample_src/s2_expectations_source.c:102]
2082616800 POINT "IDLE" - 04 00 00 00 [../sample_src/s2_expectations_source.c:77]
2082626900 POINT "END" - 05 00 00 00 [../sample_src/s2_expectations_source.c:114]
> 0 passed, 0 failed, 0 in progress, 0 not in use.
---------------------------------------------------------------------
Summary: 0 passed, 0 failed, 0 in progress, 0 not in use.
Disconnecting from device...
Saving result file...
As you can see, any test points or logs that are executed in the source under test will be reported to the console output. This provides a mean to peruse the output of your instrumented source code and do a quick sanity check of your instrumentation.
Tracing within the runner also allows filters to be applied and timeout intervals to be specified - more details can be found in the STRIDE Runner page.