Designing User Interfaces Spring 1999

1
SE 746-NT Embedded Software Systems
Development Robert Oshana Lecture
36 For more information, please
contact NTU Tape Orders NTU Media
Services [phone]
oshana_at_airmail.net
tapeorders_at_ntu.edu
2
Embedded Systems Testing Part 3
From Beatty ESC 2002
3
Agenda

• Embedded systems and real-time issues
• Automating testing

4
Embedded system software viewpoint

• Specific computations
• Math fixed point, approximations
• Error handling
• Interface to the hardware
• Resource constrained (no virtual memory)

5
Hardware issues

• Hardware interface issues
• Initialization
• Sensors wide variations in input data
• Noise
• Concurrent demands for service
• Power up, power down
• Ambiguous details of peripheral interfaces
• Watchdog timers

6
Hardware issues

• Resource constraints
• RAM, ROM, EEPROM
• Stack
• Heap
• Shared resources MUX, communication path
• Power . Sleep
• Processing capabilityload

7
Hardware issues

• Finding HW related issues
• Checklist
• Power up/power down
• Peripheral registers
• Sleep modes
• Critical analyses
• Max stack depth
• Watchdog usage
• Processor utilization

8
Hardware issues

• Whats the worst case stack depth?
• Nested subroutine calls
• Stack manipulations
• Optimizations
• Temporary variables
• Interrupts
• Each task needs a separate stack

9
Determining worst case stack depth

• Build a call tree for each task
• Determine the stack used by each function
• Determine worst case stack path through call tree
• Add stack used for each level of interrupt
• Sum stacks of each task
• Add any stack used by initialization or RTOS

10
Stack depth analysis
Stack used 12
main
Task 1
8
0
Data reduction
Service watchdog
outputs
algorithm
diagnostics
10
6
8
6
10
Curve fit
Sensor processing
LUT2x2
6
0
average
0
4
8
2
Motor drive
Temp sensor
power
Cur sensor
11
Max stack used in task 1 functions 12 8 10
12
Stack depth analysis
4
Task 2
Background
RAM test
ROM test
watchdog
4
0
2
Max stack used for task 2 4 4 8
13
Stack depth analysis
4
Task 3
Data acquisition
Current sensor
Temper sensor
Voltage sensor
4
6
2
Max stack used for task 3 4 6 10
14
Compiler issues

• Parameters passed in registers
• Optimization
• Differences between host and target
• Data representation
• Memory model
• EEPROM accesses
• Bit fields

15
Real-time systems

• Additional requirement time
• Concurrency
• Asynchronous nature

16
Asynchronous nature

• Asynchronous because
• Interrupts and events
• Widely varying work load
• Always on

17
Testing issues Multi-tasking

• Testing is unlikely to trigger the error
  conditions
• Inspection is too myopic
• Must analyze prove correctness !

18
Potential problems to check in RT systems

• 1. Mathematical operations, especially fixed
  point (scaled integers)
• 2. How are expected errors handled?
• 3. Does the Risk Analysis of FMEA identify other
  potential errors, which arent handled?

19
Potential problems to check in RT systems

• 4. Hardware interfaces
• Initialization
• Noise on sensor (and other) inputs
• Power up and power down behavior
• Power usage (sleep) modes
• Watchdog timer
• ADC and DAC turn-on delays
• EEPROM interface

20
Potential problems to check in RT systems

• 5. Resource usage (RAM, ROM, EEPROM must also be
  adequately sized)
• Adequate stack for worst case
• Intermediate data
• Data shared between ISR and application
• Data shared between tasks of different priorities

21
Potential problems to check in RT systems

• 6. Any possibility of deadlock
• 7. Schedulability of all tasks
• 8. Maximum task response times
• 9. Other task timing constraints (jitter, end to
  end requirements)
• 10. Non-deterministic structures
• 11. Task precedence constraints
• 12. Uncontrolled priority inversion

22
Things to know to analyze RT embedded systems

• 1. All mutually exclusive HW accesses, data
  accesses, kernel accesses
• 2. All places where interrupts are disabled
• 3. All shared data
• Used by every task
• Duration of critical section

23
Things to know to analyze RT embedded systems

• 4. All task precedence constraints
• 5. Additional timing constraints (jitter,
  end-to-end requirements)
• 6. All task priorities
• 7. How your compiler
• Represents all data types (native sizes)
• Writes to memory identify all non-atomic writes

24
Things to know to analyze RT embedded systems

• 8. Worst case stack (and heap) usage, as well as
  usage of other shared, limited resources
• 9. Worst case execution time of every task

25
Things to know to analyze RT embedded systems

• 10. All task timing parameters
• Release times
• Execution times
• Deadlines
• Periods
• Self-suspend times
• Non-preemption times

26
Things to know to analyze RT embedded systems

• 11. Execution time and stack depth of all library
  routines used
• 12. Kernel particulars
• Where are interrupts disables and for how long
• Resource usage stack, any other resource
• Execution time of all calls used

27
Things to know to analyze RT embedded systems

• Non-preemptible system calls
• Context switch time
• Scheduling algorithm

28
Automation
29
Automation

• What can be automated?
• Result can be deduced or is already known
• Functional
• Stimulate inputs and read outputs
• White box unit
• Once written can be executed repeatedly
• Path coverage

30
Automation

• What can be automated?
• Static analysis
• Variables read then written
• Adequate interrupt suppression
• Use of intermediate data
• Unused variables, functions, constants
• Use of magic numbers

31
Intermediate data
extern int data void Update_data(int offset,
int scale) data read_port_A( ) data
scale data offset
32
Intermediate data
extern int data void Update_data(int offset,
int scale) int temp temp read_port_A(
) temp scale temp offset data
temp
33
Intermediate data
extern int data void Update_data(int offset,
int scale) int temp temp read_port_A(
) temp scale temp offset disable_inter
rupts( ) data temp / when write to data is
non-atomic / enable_interrupts( )
34
Automation

• What can be automated?
• Dynamic analysis
• Variables read before being written
• Arithmetic overflow
• De-reference of NUL pointer
• Division by zero
• Timing data

35
Software tools

• Static analysis / dynamic analysis
• Scripting
• Capture and playback
• Test organization and status reporting
• Test harness generators
• Automated execution
• Some instrument the code to provide visibility
  and report-ability!

36
Software tools

• TestQuest Pro
• Understand C
• PC-Lint
• Polyspace
• Rational Test RealTime

37
Tools

• TestQuest Pro automated black box testing
• Capture and playback scripted (PC host)
• Uses modules to simulate inputs and capture
  outputs
• Keyboard/keypad/touch panel
• USB and IR
• Video and audio
• Optimized for PC like devices

38
Tools

• Understand C - analyze, document, and measure
• Ada, C, C, Fortran
• Excellent forward/backward call and include trees
• Details on variables, classes, structures,
  routines
• Dozens of metrics OO, complexity, size
• Fast and easy to use
• Perl and C API
• 500

39
Tools

• PC Lint static analysis
• C and C
• Customizable (200 options)
• Finds the uninitialized, unused, unreachable
• Loss of precision, mixed sign arithmetic
• gt 750 different errors, warnings, and info
  messages (overwhelming?)
• Text based
• 200 (PC version)

40
Tools

• PolySpace automated source code generator
• Finds run time errors defined in C or Ada
  standard
• De-referencing null or out of bounds pointers
• Out of bounds array access
• Read access to uninitialized data, etc
• Many others

41
Tools

• PolySpace automated source code generator
• Drawbacks
• Code conversion process (day or two)
• High processing power requirements
• Non-trivial learning curve
• C and Ada only (maybe C)
• 30K one year license

42
Tools

• Rational Test RealTime unit testing, coverage
• Automated template script for function tests
• Runs on target through ICE
• Good for regression testing

43
Tools

• Rational Test RealTime unit testing, coverage
• Drawbacks
• Only function based (no system integration level)
• Functionality available dependent on ICE
• 10K plus training

44
Automation

• Consider automating tests when
• Re-use
• Regression
• Long product life
• Complex product
• Machine readable specs, design, code

45
SE 746-NT Embedded Software Systems
Development Robert Oshana End of
lecture For more information, please
contact NTU Tape Orders NTU Media
Services [phone]
oshana_at_airmail.net
tapeorders_at_ntu.edu