-
Notifications
You must be signed in to change notification settings - Fork 0
/
deliverable3.txt
164 lines (123 loc) · 9 KB
/
deliverable3.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
===ESTR_UART===
**OVERVIEW**:
This programs performs a basic test on the the mirror function of the UUT by sending a
"mirror on" character (`), a short message (123) then a mirror off character (') via UART0.
The UART0 RX pin is then monitored for the correct response. The test will print PASS on the
stellaris screen if it is successful, "Fail wrong received" if an incorect character is
received and "Timeout" if no character is received within 1.5 seconds.
Optionally, pin G4 on the ESTR can be connected to the reset pin on the UUT. The ESTR will
pull this pin low when starting up, ensuring the UUT is reset and in the correct state
before testing begins.
**DIRECTIONS**:
Simply connect the UUT UART pins to the UART0 pins on the ESTR. Testing begins
automatically on startup.
**ORGANISATION**:
The testing code is made up of three separate tasks which utilyse queues to safely interchange
data. One task is dedicated to sending data via UART to the UUT but will later be modified to
be used to send data to the PC. Another task is for monitoring received UARt messages from the
UUT and again will later be extended to send to the PC as well. The last task is used for keeping
track of time.
Within the UART_ESTR directory there are a number of modules in addition to the standard RTOS
and Stellaris library files. The modules were created to help organize aspects of the code
according to functionality. The modules were setup so as to be easily extended at a later point.
The addiional modules are:
Stopwatch.c and .h -->This module implements the stopwatch function. This function is also
used in the GPIO test.
UART.c and .h -->This module initializes the UART port on the ESTR contains functions that
implement interupt driven sending and receiving.
uut_gpio.c and .h -->This module is use for initializing and controlling GPIO pins on the
ESTR that directly interact with the UUT. In this case it is only used for
the controlling
the reset pin on the UUT. This code will later be merged with the
uut_gpio module used in the GPIO tests.
Ideally a separate task for displaying messages on the ESTR screen would be implemented but as
the ultimate goal is to use the PC for this task the module was not implemented.
**WHAT THE PROGRAM DOES**:
The program starts by running various initializations. Next the three tasks are started. The "UART send"
task then transmits the mirror toggle character then the test message followed by another mirror
character. After this data is sent, an 'S' character is sent via a queue to the timeout task.
The time out task will then start a watchdog timer. The timer is reset after receiving a character
from the UARTreceinging task via the same queue. If the receiving task receives a message via uart
it is then compared to the sent message using a call to srtncmp. If the message is correct then the
word "passed "will be displayed on the screen.
The test is fairly basic and represents a work in progress. The test will later be extended to transmit
larger messages and will be modigied to send characters without first sending the mirror togling character.
===ESTR_GPIO===
System primarily works around uut_gpio.c, the uut_gpio_init() sets up gpio data direction etc before registering
the airspeed response interrupt and registering an airspeed stimulus task that performs the test.
test a. requires the uut be stimulated with a varying width varying frequency pulse train with checks to ensure 1:1 response
and that response latency is within a reasonable limit.
tests should at some stage push limits and determine the failure point of the
uut. With regard to the airspeed system this could happen one of two ways,
either the pulse width will become too narrow to be detected by the uut, or
the frequency (or pusle to pulse interval) has increased to the point where
the uut might not respond in time (ie the interrupt has not been serviced before
the next arrives). Ultimately the quadrature encoder selected for use would
determine which of these failure modes would occur first. If the duty cycle
of the encoder was anywhere close to 50% (a logical assumption) the frequency
based failure will occur first (this because the response latency of the ISR is significantly
larger than the time period required to charge the wire capacitance and for
the interrupt to occur). This would essentially dictate that to determine the
limit of operation we need to know the minimum pulse-to-pulse interval the
system can reliably respond to, this is covered in task b. A more pertinent
test would be to simulate normal operation for an extended period
and ensure that the uut will reliably respond. This is what was implimented.
The test simulates normal operation by generating a fixed duty cycle waveform
and increasing the frequency (this satisfiess the variable pulse width / variable
frequency requirement). The frequency increases to a set limit and once reached,
resets to a predefined starting frequency. This is done numerous times simply to
increase the total number of pulses to which the uut must respond (ie testing
long term reliability). The test checks for reasonable latency and 1:1 response
as follows. Before raising the pin state, a response flag is set to zero, every
time the response ISR is executed, this flag is incremeneted. As such at the end
of the cycle, before generating the next rising edge, if the flag does not equal
one, the ISR has either not been entered at all, or more than once. Currently
the system does not destinguish between missed responses and extra responses,
but the total number of 1:1 response failes (the sum of both, missed and
extra responses) is displayed at the end of the test. Latency is measured using the
stopwatch system.
The stopwatch system works uses timing hardware already configured for FreeRTOS
and as such offers minimal overhead. FreeRTOS configures and uses the systick
timer to maintain a real time clock. The value of this RTC can be accessed with
xTaskGetTickCount(). This provides accurate timing for large intervals but with
coarse granulatiry. To achieve better accuracy for measuring small intervals the
current value of the systick register can also be read. A stopwatch instance is
started by storing the tick (xTaskGetTickCount()), and subtick (SystickGetValue())
values in a stopwatch_t instance. After some intervalthe stopwatch will be stopped
at which point ticks and subticks will be read again. The interval measured with
the stopwatch can then be read with a very high dynamic range by summing the time
differences represented each of the recored values of ticks and subticks. This
architecture was chosen to provide the best inter-task operability.
Ie a stopwatch can be started in a task, stopped in an ISR, and then finally be
read in the origional task.
Currently both the stopwatch instance used to measure latency, and the response flag
are unprotected global variables. At this stage the behavior of the interrupt is
reliable and predictable, but as the project develops a more robust system will be required.
From simply observing the uut ISR execution on a scope, it is apparent that there
are two higher priority interrupts occuring, one lasting 1.1uS and the other 20uS.
The baseline execution time of the ISR is 16uS, so the maximum expected execution
time for the interrupt is 37.1 uS. The lag period before ISR execution starts is
also extremely variable, and likely constitutes the primary cause for 1:1 response
failure. The minimum pulse-to-pulse interval was set by visually observing the uut
response on an oscilloscope and ensuring that the uut would always have adequate time
to respond to the pulse. As mentioned before this was done to ensure that this test
would not stress the resonse of the stellaris and simply test reliable operation
over an extended period.
Currently the structure of the code places a very high weight on the uut_gpio
module, which in it's current state would be more aptly named the test_one module.
Attempting to make the uut_gpio module impliment functions to perform all the tests
(the origional plan) could make it extremely large and confusing, so a better
structure can no doubt be attained. Though this will also be largely dependant on
what we eventually use as a control method. If we do indeed use a python controller
to load the output files for each individual test onto the ESTR, the best structure
might be to have a seperate module for each test, with #ifdefs in the main file
to controll which tests modules are included and run.
===ESTR_UART===
===PC_code===
This program loads tests on to the Stellaris by using "LM Flash Programmer"
from Texas Instruments. This loads the .bin files located in "testBins". At
the moment, test1.bin is the UART test, and test2.bin is the GPIO test.
Inside a while loop, the code asks for the test number and then loads the
corresponding binary file to the Stellaris.
These .bin files must be copied from the "Debug" folder generated by Code
Composer Studio. Currently there is no UART support for deliverable three.