Test group Test case name Test case description
Coverage C and assembly coverage test The test procedure verifies coverage results consistency by using special reference comments. The test procedure starts the code coverage and runs the test function. Test function includes generic C code and CPU specific assembly code, which is decorated with reference comments to indicate the correct coverage result. Expression coverage is tested on all targets that support coverage and conditional coverage is tested on targets that support it. Assembly code is written for each CPU separately and covers all conditional jumps that the architecture provides. C and assembly code coverage are then checked against the reference comments and if the results match the expected, test passes.
Coverage Save, close and reopen test This test procedure tests if all data is retained when saving, closing and reopening the coverage document. The test procedure saves and closes the coverage document. This document is then reopened and the results are compared to the reference values. If values match, test passes.
Coverage XML schema validation test Coverage export XML files for various export combinations are validated against XML schema definition.
Coverage Endless coverage test The test procedure verifies the operation of the endless coverage. Test sets up a coverage .trd file for endless coverage recording. CPU is ran until the endlessCoverageTest function. The coverage session is started and the CPU is set to run past this function. Function includes endless loop, where the buffer is immediately overflown. Test waits for 1s for the buffer to overflow and then a flag is set to release the CPU from the endless loop. CPU then stops outside this function. If it doesn't stop, test fails. Coverage data is then analyzed to verify, that both parts of the function - before the FIFO overflow and after the FIFO overflow - are covered. If both parts are covered test passes, otherwise it fails.
DAQ Real time performance test The test procedure measures the impact of DAQ on the application execution Test procedure first runs the application so that a test loop is executed without the DAQ enabled. The loop incrememnts the test variable for a certain period of time and stores its final value. Then the same loop is executed again, this time with DAQ enabled. Test returns the final values ratio.
DAQ Max sampling rate test The test procedure measures max sampling rate. Test procedure runs the test loop with DAQ enabled for one and ten variables. In each case it reads the maximum loop time for each session and reports it in microseconds.
DAQ Time stamp and data value test The test procedure verifies the DAQ time stamps and aquaried data values. Test enables the interrupts and runs DAQ of the interrupt counter. After one second the target is stopped and interrupts disabled. If there are no records in the acquired data, test fails. Periods between the samples are then compared to the reference period and if the periods differ more than the tolerance permits, test fails. After that values are checked if they are in expected increasing order. If not, test fails.
Debug Internal memory programming test This procedure tests internal memory programming. Test verifies the download report file and checks if there are any records of overlapping ranges and ranges that failed to download correctly. If there are such errors, test fails.
Debug External flash programming test This test verifies external flash programming. The test opens the flash programming log file and reviews its contents. The test checks if programming passed (there is no word FAIL in the report) and if verification process passed (test report states Verify OK).
Debug Get address test This test procedure verifies CDebugFacade class call GetSymbolInfo() return object CSymbolInfo methods: getMemArea(), getSizeMAUs(), getMTypem()._byType, getMType().m_byBitSize, getAddress() of variable and function. Test stops on the line where the test variable is being incremented. First the symbol information is read and compared to the reference information. The variable is then incremented and its value is read from the variable symbol address. If the value matches the reference value, test passes. Next the test function symbol address is read and the target is set to run until this address and then again until return, where the test variable value is changed. The test variable value is then compared to the reference value and if the values match, test passes. After that the variable and function addresses are read and compared to the addresses that we got from the symbol information. If the values match, test passes.
Debug Read and write memory test This test procedure verifies CDebugFacade readMemory() and writeMemory() methods. The test first verifies reading 1, 2, 4 bytes from an address by comparing the read values to the reference values. After that it writes 1, 2, 4 bytes to an address and then compares the written values with the values that are read back from this address. Values are compared for every separate read and write test and each of them is reported as passed or failed accordingly.
Debug debugNumberOfSFRsTest() This test procedure verifies number of Special Function Registers (SFRs) for specific CPU primary core. CDataController2 method getCPUSFRs() is used to get a number of provided SFRs for specific CPU. Test passes if number of SFRs exceeds minimum number of SFRs for specific CPU.
Debug debugSFRGroupsTest() This test procedure verifies content of Special Function Register (SFR) groups. CDataController2 method getCPUSFRs() is used to get the SFRs groups/registers for specific CPU. Test passes if each SFR group contains at least one register.
Debug Read and write register test This test procedure verifies CDebugFacade readRegister() and writeRegister() methods. This test procedure verifies general purpose registers read and write functionality, using predefined values as a reference. Current register values are stored and finally restored to original state. Register values are read using readRegister() method and compared against reference values. writeRegister() method writes predefined values to general purpose registers, which are then read and compared against reference values.
Debug Read and write value test This test procedure verifies CDebugFacade class readValue() and writeValue() methods. The readValue() reads value from the test variable previously set to a specific value and compares it to the reference value. The writeValue writes predefined value to the test variable and then reads it and compares the two values. If values match, test passes, otherwise it fails.
Debug Evaluate and modify test Tests the CDebugFacade evaluate() and modify() methods. The test application contains an infinite loop, which is broken at testEvaluateModify breakpoint. At that point global and local variables are already set to a specific values. Reference comment values are used to evaluate global and local integer variable. Modification of a global integer variable with a literal constant and modification of a integer/float local variables with an expression are verified with previously tested evaluate call.
Debug Run until function test Tests the runUntilFunction() method. The test flag is first set to enable the test to reach the test function. The target is set to run until the test function. The test then waits for the target to stop. If timeout occured before the target stopped, test fails. If the target stopped in time, the address of the test function is determined. If the program counter value matches the function address, test passes. Otherwise test fails.
Debug Step a source line test Tests stepHigh() method. A breakpoint is first set on a line where the function will be tested. The test flag is set to enable the program flow to reach the test code. The target is then set to run and the test waits until it is stopped. If timeout occurs, test fails. Otherwise the reference value for the test variable is stored and the test steps the source line, where the value of the test variable is changed. The test variable is then evaluated and it's value is compared to the reference value. If the evaluated value matches the expected value, test passes. Otherwise test fails. All breakpoints are then deleted. The test flag is cleared and the target is set to stop.
Debug Run test Tests the setCPUMode("run") method call. The target is set to run. If the function returns information that the target is running, test passes. Otherwise it fails.
Debug Stop test Tests setCPUMode("stop") method call. The target is set to stop. If the function returns information that the target sucessfully stopped, test passes. Otherwise it fails.
Debug Get CPU status test Tests the getCPUStatus() method. A breakpoint is first set on a test point. Test flag is set to enable program flow to reach the test code and the target is run. CPU status is checked if it is set to running. Test flag is set that enables program flow to reach the previously set breakpoint. Test then waits for the program execution to stop. If the CPU status correctly indicated that the target was running and the target stopped before the timeout, test passes. Otherwise test fails. All breakpoints are then deleted and the test flag is cleared. Target is set to stop.
Debug Reset test Tests the reset() method. Reference values, one for the value before the reset and one value for after reset, are read. A breakpoint is then set on a test point and program is set to run to reach the breakpoint. The test flag is then set to enable program flow to reach the test code. The test steps the source code, where the value of the test variable is changed. The target is then reset and all test flags are cleared. Debug test flag is then set and target is set to run. The test waits for a limited period of time for the target to actually run. After that the target is stopped. Value of the test variable is evaluated. If the value matches the reference value stored previously, test passes. Otherwise test fails.
Debug Step over a source line test Tests the stepOverHigh() method. First the address of the destination source line is determined. The test flag is then enabled, so that test procedure can reach the test code. If address is found, program is run until this address. If address is not found, test fails. Value of the test variable is evaluated, step over a source line is made and then the variable is evaluated again. Values are compared and if the second value is increased by one as expected, test passes. Otherwise test fails. The test flag is then cleared.
Debug Step the instruction test Tests the stepInst() method. First the address of the destination source line is determined. Test flag is then enabled, so that test procedure can reach the test code. If address is found, program is run until this address. If address is not found, test fails. Test then steps into an instruction. Address of the test source line is then determined. If it doesn't exist, test fails. If the address matches the current program counter value, test passes. Otherwise test fails.
Debug Step over an instruction test Tests the stepOverInst() method. Test continues from the location where the previous test ended. First a step over an assembler branch is made. Address of the test point is then determined. If it doesn't exist, test fails. The address of the test point is then compared to the value stored in the program counter. If the values match, test passes, otherwise it fails. Test flag is then cleared and all breakpoints are deleted.
Debug Set a breakpoint test Tests the setBP() method. First a filename and line of the reference comment are determined, where we want to set the breakpoint. Breakpoint is then set on the chosen line. Test flag is set, so that the program flow can reach the breakpoint. Target is then set to run. When the execution stops the value of the test variable is first evaluated. Then test procedure executes next statement, which increments the value by one and the variable is evaluated again. Values are then compared. If the first value is one less then the second, the test passes, otherwise it fails.
Debug Delete a breakpoint test Tests the deleteBP() method. Breakpoint from the "Set breakpoint test" remains set and the target is set to run for 10 seconds. If the target is stopped by then the breakpoint is deleted and the target is set to run again. Target status is checked again. If target keeps running, test passed. If either target stopped after the breakpoint was deleted or the target didn't stop on the breakpoint to begin with, test fails.
Debug Enable / disable breakpoint test Tests the setEnabled() method. After the "Delete breakpoint test" the target is running and the test procedure first stops the target. Breakpoint is then disabled and the target is set to run again. Test procedure then checks if the target is running. If it is running, the breakpoint is enabled and test waits for the program execution to stop. If it stopped, test passes. If it didn't stop, or if it didn't run at all, test fails. All breakpoints are then deleted and test flag is cleared.
Debug Breakpoint At Symbol test Tests setBP() on specific symbol. Breakpoint is first set on the test symbol. Test flag is set, to enable program flow to reach the desired breakpoint. Target is set to run and the test procedure waits for the program execution to stop. Test procedure then steps out of the test function. Value of the test variable is incremented during these steps. Test variable is then evaluated and it's value compared to the reference value. If the value is as expected, test passes, otherwise it fails. Test flag is then cleared and all breakpoints are deleted.
Debug Breakpoint At Address test Tests setBP() on specific address. First the address of the test function is acquired and a breakpoint is set on this address. The test flag is set to enable program flow to reach the desired function. Target is then run. Test procedure waits for the target to stop and then steps out of the test function. In this steps the value of the test variable is changed. Test variable is then evaluated and it's value compared to the reference value. If the value is as expected, test passes, otherwise it fails. Test flag is then cleared and all breakpoints are deleted.
Debug Software Breakpoint test Tests the functonality of software breakpoints. First all breakpoints are removed. Then the test sets consecutive Hardware Breakpoints until they have all been used and no more can be set. When this happens, the test switches to Software Breakpoints. If necessary, download is performed again. When Software Breakpoints have been enabled, one more breakpoint is set. If download was required to enable Software Breakpoints, all breakpoints are now Software Breakpoints, otherwise only the last breakpoint is a Software Breakpoint. After that, the test steps back into the main debug testing function. The test flag is then set to enable the program flow to reach the set breakpoints. For each set breakpoint the target is set to run and the test waits for the program to stop on the breakpoint. If the timeout is reached before the target stops, the breakpoint name is added to the list of failed breakpoint tests. The test procedure then steps over the set breakpoint. In this step the value of the test variable is changed. This value is then compared to the reference value. If the values don't match, the breakpoint name is added to the list of failed breakpoint tests. When all breakpoints have been tested, they are deleted and breakpoints are switched back to the Hardware type. The test flag is cleared. If there are items in the list of failed breakpoint tests, the test fails and returns the error message with the list of failed breakpoint tests.
Debug Goto test Tests the gotoFunction() method. The test executes the Goto option and calls a test function. A test variable is evaluated and it's value is stored. If the address of the destination source line is found, the target is set to run until that source line. The test variable is then evaluated again. If the correct section of the program was executed, the value of the test variable should be increased by one. If this is the case, test passes, otherwise it fails.
Debug Second Core Test The test procedure tests basic debug functionality on a second core sample on a multicore target. The test stops the CPU if it is running and opens the workspace of the second core. All breakpoints are deleted and download is performed on the second core. A breakpoint is set in a function that runs on the second core. Next, a function is called on the primary core that enables the second core. The second core is supposed to be running when enabled. If it doesn't run, test fails. If it runs it cycles through the endless loop. The test flag is then set that breaks the endless loop and program should stop on the breakpoint that was set earlier. If program execution doesn't stop, test fails. The test procedure then steps over a source line, that sets a specific value to the flag, which is then compared to the reference value. If values match, test passes, otherwise it fails. Lastly the second core workspace is closed.
Debug debugSecondCoreForSFRsTest() This test procedure verifies number of Special Function Registers (SFRs) for specific CPU secondary core. CDataController2 method getCPUSFRs() is used to get a number of provided SFRs for specific CPU. Test passes if number of SFRs exceeds minimum number of SFRs for specific CPU secondary core.
Debug Access Breakpoint Test Test procedure checks access breakpoint functionality when writing to or reading from char, short and long variables. Program is set to run until a breakpoint, which is located in the beginning of the endless loop. A test flag to enable Access Breakpoint test is set. This flag allows program flow to reach functions that test all Access Breakpoint functionalities. All breakpoints are deleted to ensure program won't stop unexpectedly. Then test functions are called depending on target combination capabilities, which test each separate Access Breakpoint functionality - read char, write char, read short, write short, read long and write long. All functionalities are tested in the same manner. First, a Hardware Breakpoint is set on a variable. Program is set to run and while it loops in the endless loop, a test flag to enable specific test is set. Program is then expected to stop on the Hardware Breakpoint that we set on the variable. Test procedure waits for a predetermined period of time for the program to stop. If it reaches a timeout, an error message is issued and test fails. If the program stopped in time, then the test proceeds to check if program execution stopped on the Hardware Breakpoint without executing the source line. If it did, test executes the source line, which increments the value of the variable by one. Test then steps the source code one more time and compares the value of the variable to the reference value. If values match, then test passes, otherwise test fails and reports the error. The test flag for running the test is then cleared and all Hardware Breakpoints are removed.
Debug CValue Type Test This test procedure evaluates SType and CValueType isystem.connect methods, using 8 bit signed values. Verification is done against predefined reference values, checking signed, unsigned and overflow values.
Flash Read and write tests This test procedure tests CDataController writeMemory() and readMemory() functionality and verifies that writing to flash does not permanently change clock settings. The test procedure first runs an endless loop and measures the number of loop repetitions and saves the measured reference value. Then it writes a known value to a predetermined location in the flash memory. The value is then read back from the flash memory and compared with the written value. The number of loop repetitions is then measured again. If written and read values match and if the measured number of repetitions after the write to flash is in range of 5% of the reference one, test passes.
Flash Mass erase test This test procedure verifies the mass erase functionality. Test procedure mass erases the flash and then reads the memory from the predetermined location. If all values in this buffer equal the mass erase values specific for the target, test passes. Otherwise it reports the failed locations.
Flash Target download into the code flash This test procedure tests CLoaderController targetDownload() functionality. The test procedure loads file with known values into the target code flash. Code flash is then read back and compared with the written value. If values match, test passes.
Flash Target download into the data flash This test procedure tests CLoaderController targetDownload() functionality. The test procedure loads file with known values into the target data flash. Data flash is then read back and compared with the written value. If values match, test passes.
Flash Full FLASH download test This test procedure verifies that whole available FLASH can be downloaded to. The test procedure verifies that complete FLASH can be downloaded to. Download file is dynamically created to fill whole FLASH. Download is performed and if verify passes, test passes.
HIL HIL write test The test procedure verifies the CHILController write() method. Target processor is reset and run until dummyFunction(). Processors general purpose input output pads are configured as inputs (read operation). Hil modules digital/output lines are physical connected to selected target pads. Hil output lines are first set to high logic level. Current processor input pads logic levels are read and test passes if they match to hil output logic levels (high). Then hil output lines are first set to low logic level. Current processor input pads logic levels are read and test passes if they match to hil output logic levels (low).
HIL HIL read test The test procedure verifies the CHILController read() method. Target processor is reset and run until dummyFunction(). Processors general purpose input/output pads are configured as outputs (write operation). Hil modules digital input lines are physical connected to selected target pads. Target processor output lines are set to low logic levels. Hil input lines are read and test passes if they match to processor output lines logic levels (low). Then processor output lines are set to high logic level. Hil input lines are read and test passes if they match to processor output lines logic levels (high).
HIL HIL getDescriptors test The test procedure verifies the CHILController getDescriptors() method. Target processor is reset and run until dummyFunction(). GetDescriptors method is called and test is passed if no exception raised.
IO Module Digital input / output test DigitalInputOutputTest() verifies digital output and digital input lines. Each digital output line is physically connected to corresponding digital input line (use loop-back connection cable). Target processor is reset and run until dummyFunction(). All digital outputs are first set to high logic level using hil write method. Current digital input values are captured using hil read method and test passes if digital input/output lines logic levels match. Described test method is then repeated by setting low logic levels to digital output lines.
IO Module Analog input / output test This test verifies analog output and analog input lines. Each analog output line is physically connected to corresponding analog input line (AOUT0 to AIN0 and AOUT1 to AIN1; use appropriate cable). Target processor is reset and run until dummyFunction. All analog outputs are first set to +4.0 V level, using hil write method. Current analog input values are captured using hil read method. Test passes if voltage levels difference is less than 5 percents. Described test method is then repeated by setting -4.0 V level. WARNING: do AOUTx and AINx zero adjustment before starting this test (Hardware->Tools->I/O module calibration).
IO Module Pattern test This test validates IO module pattern generation. Analog output 0 and analog input 0 line are hard-wired (use appropriate cable). Analog out 0 line is set to pattern mode and profiler configuration is loaded with AUX profiler section enabled. Processor is started and ramp generation file is loaded via hil write method. Profiler and processor are stopped. Recorded data (analog input 0) is analyzed (regression line generated) and compared to expected value. Test passes if both lines (ideal ramp and regression line) are similar (comparing gradient coefficients).
IO Module Power probe test This test verifies power probe board and IO module II, revision C and up. Power probe board is connected according to the IO module documentation. Power probe jumpers are set to following positions: voltage range selection is 20V, current range selection is 1A. All parameters needed to start power measurement are automatically set/reset via script. Voltage and current values are measured via hil read call. Test passes if difference between measured and reference power consumption (in percent), is less than given tolerance value.
IO Module Trigger out test This test checks trigger out line functionality. Digital out 0 is hard-wired to digital input 0 line, Trigger out line is hard-wired to digital in 5 line (use appropriate cable). Trace is configured to start recording when digital input 0 is at high logic level. Digital out 0 is first set to low logic level, trace and processor are set to run mode. Digital out 0 is set to high logic level. Trace and processor are set to stop mode. Trace results, specifically digital input 5 logic level, is analyzed and test passes if digital input 5 signal switches from high to low logic level.
IO Module Trace test This test verifies aux lines trace/profiler functionality. Test enables interrupt which toggles gpio line (CPU specific). Gpio line is connected to the IO module digital input DIN0 pin. Profiler records AUX lines. Results are analyzed and test passes if toggling period equals to the referenced interrupt period.
IO Module Trace test with internal and external clock This test verifies aux line and data trace/profiler functionality. Test enables interrupt which toggles gpio line (CPU specific). Gpio line is connected to the IO module digital input DIN0 pin. Profiler records AUX lines and specified data state variable. Profiler is executed twice, once using internal and then with external system clock (use io module with soldered oscillator).
isystemConnect API Backward compatibility test Backward compatibility test...
itest itest test This test procedure verifies itest functionality. Target is set to run until the dummyFunction. At that point target is initialized. The test then runs a series of test cases which are described in iyaml test specifications. Test cases cover a variety of itest functionalities: calling functions with various parameters and return values, stubbing the function calls to return predetermined values, user stubbing the function calls with chosen functions, coverage execution, profiler execution, trace execution, setting HIL parameters, setting winIDEA Options and running scripts. Only tests that are supported by the target system are executed. Some are disabled with the use of tags and some are disabled after checking the function availability. Each test case is reported as successful or failed, depending on the result when the test is ran. Additionally, the target must continue to function normally for itest test to pass. If an exception is encountered, test fails.
Low Power Mode Low power mode test This test procedure tests low power mode handling. For each available low power mode test guides the program execution to the targetEnterAndExitLowPowerMode function and sets the flag, corresponding to the tested low power mode (e.g. gotoStandbyLowPowerMode, where "Standby" is the tested mode). Test runs the application, which enters and exits the low power mode. Test polls the CPU status and checks if the CPU first entered HALT mode and then RUN mode. Each transition must be completed in 5 seconds, else the test fails. Program execution continues on one of the three possible locations - reset, interrupt handler or it continues from the point where the low power mode was entered, depending on the CPU and the application. All these locations have apropriate source code written, where the program execution is caught in an loop after exiting the low power mode. Test then sets a breakpoint in this loops and waits for 5 seconds, for the application to stop on this breakpoint. If it doesn't, test fails. Test checks whether the wake-up location is correct by comparing the callSource parameter of the onExitLowPowerModeTestBreakpoint function and the reference wake up location and stores the result. Test then sets the loop condition to false, deletes all breakpoints, sets a breakpoint after the loop and runs until stopped on breakpoint. If it doesn't stop in 5 seconds, test fails. Breakpoint is then stepped over, so that a test variable loopFlag changes its value. All breakpoints are deleted and the flag for the specific low power mode test is cleared. Finally, test compares the reference and actual value of the loopFlag variable and checks if the wake-up location was correct. If both conditions are met, test passes, otherwise test fails.
Multiple symbol table test Multiple symbol table test This test procedure verifies multiple symbol table test functionality. Test defines two download files, the primary and secondary. The primary one calls function located inside secondary download file. One source file is linked to both download files. Test is based on code profiler and verifies the functions call count numbers.
Profiler Profiler without interrupts test This test procedure tests profiler execution and results. Profiler without interrupt test runs previously defined trace file. Trace file includes code and data sections according to specific target capabilities. Code profiling defines a list of functions for profiler evaluation with explicit naming convention and wildcard resolving into two function names. Data profiling includes one global variable for profiler evaluation. If target supports both data and code profiling, then all three profiler combinations are separately tested (profiling code, profiling data and profiling both). Test starts trace recording, following program execution. Profiled functions are executed for a predetermined number of loop counts. Reference values are given by source code instrumentation comments. Test verifies each function count number and validates call time for one of profiled functions. Profiled function executed for specific time and divided by execution count number represents a call time reference value. Data area symbol is modified (write access) during program execution. Specific values are written to symbol for a predetermined number of counts. Reference values are given by source code instrumentation comments. Test verifies each symbol value count. If the target system supports either ITM, OTM or WDDATA profiling, test verifies if the expected messages were produced and recorded during the program execution.
Profiler Profiler with interrupts test This test procedure tests profiler execution and results when interrupts present. Profiler with interrupt test runs previously defined trace file. Trace file includes code and data sections according to specific target capabilities. Code profiling defines a list of functions for profiler evaluation with explicit naming convention and wildcard resolving into two function names. Data profiling includes one global variable for profiler evaluation. If target supports both data and code profiling, then all three profiler combinations are separately tested (profiling code, profiling data and profiling both). Test starts trace recording, following program execution with defined interrupt handler. Profiled functions are executed for a predetermined number of loop counts. Reference values are given by source code instrumentation comments. Test verifies each function count number. Test also verifies interrupt handler time period. Reference time period for interrupt handler is given as a code instrumentation value (reference value given as a result of oscilloscope measurement). Data area symbol is modified (write access) during program execution. Specific values are written to symbol for well known counts. Reference values are given by source code instrumentation comments. Test verifies each symbol value count.
Profiler Profiler with continuous mode test This test procedure tests profiler execution with continuous mode selected. Profiler with continuous mode test runs previously defined trace file. Trace file includes code sections according to specific target capabilities. Code profiling defines a list of functions for profiler evaluation with explicit naming convention and wildcard resolving into two function names. Test starts trace recording, following program execution. Profiled functions are executed for a predetermined number of loop counts. Reference values are given by source code instrumentation comments. Test verifies each function count number and timestamp for one trace record. Negative time is expected due to continuous mode selected.
Profiler XML schemas validation test Profiler export XML files for various export combinations are validated against XML schema definition.
Profiler Profiler without interrupts test This test procedure tests profiler execution and results. Profiler without interrupt test runs previously defined trace file. Trace file includes code and data sections according to specific target capabilities. Code profiling defines a list of functions for profiler evaluation with explicit naming convention and wildcard resolving into two function names. Data profiling includes one global variable for profiler evaluation. If target supports both data and code profiling, then all three profiler combinations are separately tested (profiling code, profiling data and profiling both). Test starts trace recording, following program execution. Profiled functions are executed for a predetermined number of loop counts. Reference values are given by source code instrumentation comments. Test verifies each function count number and validates call time for one of profiled functions. Profiled function executed for specific time and divided by execution count number represents a call time reference value. Data area symbol is modified (write access) during program execution. Specific values are written to symbol for a predetermined number of counts. Reference values are given by source code instrumentation comments. Test verifies each symbol value count. If the target system supports either ITM, OTM or WDDATA profiling, test verifies if the expected messages were produced and recorded during the program execution.
Profiler Profiler with interrupts test This test procedure tests profiler execution and results when interrupts present. Profiler with interrupt test runs previously defined trace file. Trace file includes code and data sections according to specific target capabilities. Code profiling defines a list of functions for profiler evaluation with explicit naming convention and wildcard resolving into two function names. Data profiling includes one global variable for profiler evaluation. If target supports both data and code profiling, then all three profiler combinations are separately tested (profiling code, profiling data and profiling both). Test starts trace recording, following program execution with defined interrupt handler. Profiled functions are executed for a predetermined number of loop counts. Reference values are given by source code instrumentation comments. Test verifies each function count number. Test also verifies interrupt handler time period. Reference time period for interrupt handler is given as a code instrumentation value (reference value given as a result of oscilloscope measurement). Data area symbol is modified (write access) during program execution. Specific values are written to symbol for well known counts. Reference values are given by source code instrumentation comments. Test verifies each symbol value count.
Profiler Profiler with continuous mode test This test procedure tests profiler execution with continuous mode selected. Profiler with continuous mode test runs previously defined trace file. Trace file includes code sections according to specific target capabilities. Code profiling defines a list of functions for profiler evaluation with explicit naming convention and wildcard resolving into two function names. Test starts trace recording, following program execution. Profiled functions are executed for a predetermined number of loop counts. Reference values are given by source code instrumentation comments. Test verifies each function count number and timestamp for one trace record. Negative time is expected due to continuous mode selected.
Profiler XML schemas validation test Profiler export XML files for various export combinations are validated against XML schema definition.
SlowRun Slow run test This test procedure tests slow run mode. Slow run test is based on code profiler. Slow run mode is enabled and code profiler configured. Then processor is started and test passes if function execution count equals to reference one.
Software Trace Software trace test This test procedure verifies software trace functionality. Test configures the profiler according to the specific analyzer type - software trace in this case. The instrumented functions and variable writes are executed by the processor for the predetermined number of times and recorded with the profiler. Test first verifies if the profiler successfully started and if it stopped on the breakpoint as expected. Recorded data is then exported to XML. XML file is analyzed and the test verifies the function call count and data values by comparing them to the reference values retrieved from the special reference comments in the source code.
Trace Trace trigger test This test procedure verifies different trace triggers. Test procedure runs the test code in a loop. For each different trigger (On Trigger, Immediately, Continuous, Break on Trigger) the test code is ran and trace executed. Trace results are then analyzed if they include the expected records.
Trace XML schema validation test Trace export XML files for various export combinations are validated against XML schema definition.
Trace ETB trace test This test procedure verifies the operation of ETB trace. Test selects ETB for trace and creates new trd file called etbTrace.trd. CPU is run until function traceTriggerStart. Trace session is started and the CPU is set to run until traceTrigger5 function. The analyzer is then stopped and the recording is saved. Recording is exported to XML and XML is then parsed to check if all expected records are found. If all expected function calls are recorded, as well as all expected writes to a variable are detected, test passes. Otherwise test fails.
User Trace Port User trace port test This test procedure verifies user trace port functionality. Test configures the profiler according to the specific analyzer type - user trace port in this case. Function calls and data writes/reads are instrumented with code that toggles MCU pins. The instrumented functions and variable writes are executed by the processor for the predetermined number of times and recorded with the profiler. Test first verifies if the profiler successfully started and if it stopped on the breakpoint as expected. Recorded data is then exported to XML. XML file is analyzed and the test verifies the function call count and data values by comparing them to the reference values retrieved from the special reference comments in the source code.