18-348 Lab #6

Relevant lectures:
- Part A: Lecture 10. Serial Ports
- Part B: Lecture 11. Debug and Test

Links to all files referenced in the lab and prelab can be found in the Files section at the end of this document.

Pre-Lab 6 - Part A:

Refer to Chapter 13 of the MCU9S12 Datasheet for details of the Serial Communication Interface. Refer to the lecture notes for details on serial communication.

For each table below, fill in the values from the corresponding list (Hint there are the same number of values as locations in the table. Each value should be used only once).

Review section 13.4.2. of the MCU9S12 Datasheet on baud rate generation. Note that the values in table 13-10 are incorrect for our purposes because they assume a module clock rate of 25 MHz.

For this lab we will assume that the module clock rate is 8 MHz. The following calculations should be performed assuming the clock speed is 8 MHz.

Using the formula given, fill in the SCIBR[12:0] values required for each of the listed baud rates below. Compute the actual baud rate (using the formula and the integer value you chose for SCIBR. Compute the % error using the formula:
100 * (Actual Baud Rate - Nominal Baud Rate) / Nominal Baud Rate

Implement a trigonometric sine function using fixed point math (4 bits integer; 12 bits fraction). This function is used for drawing arcs, generating acoustic waveforms, and other purposes in embedded systems. For the prelab, design a suitable algorithm. The design representation can be any reasonable mixture of mathematical formulas and a flowchart. The design:

Pre-Lab 6 - Part B:

Remember this is an individual assignment. Your test plans should be done independently. For the prelab only put your name in the spreadsheet.

Goal:

To write a testing plan

Discussion:

For this part, you will plan a white-box testing on a statechart implementation of a coin receiver for a vending machine. The state chart is shown below:

The tests you will implement are white-box tests in the sense that you will test the transitions in the state chart shown above. For the purposes of testing, you may assume that no more than one input is asserted at one time (e.g. N and D should not be pressed simultaneously).

An example test sequence for this implementation is given in the table below. The state in parentheses is the state that the controller should be in after the input. If your test reveals that the actual state is different than the expected one, you should note the actual state in the description column of T2.3 (e.g. "Transition Tx goes to state 4 instead of state 5.").

	Pass/Fail	Initial State	Input 1 (State after input)	Step 2 (State after input)	Step 3 (State after input)	Step 4 (State after input)
Test 2.1	PASS	1	N (2)	N (3)	N (4)	N (5)

Table 1: Test Sequences

The above test sequence tests arcs T1, T4, T5, and T10. The coverage of the test is recorded in the table below by placing an X in the appropriate columns. This documents traceability of tests to arcs, answering the questions "which arcs does a particular test exercise?" and "for a given arc, which tests exercise that arc?"

	T1	T2	T3	....
Test 2.1	X

Table 2: Traceability (Tests to Arcs)

Tables 1 & 2 together form a White Box Test Plan of a type commonly used in embedded industry.

Procedure:

Download the the testplan_template.xls file (use the WB_* sheets). Rename it to testplan_<andrewid>.xls.
Write additional tests for the statechart implementation. You tests must meet the following requirements:
- There shall be no fewer than 5 tests.
- Every transition in the statechart shall be tested by at least one test.
- All tests shall start in state #1 (the reset state).
Update the traceability table for the tests that you write. Use the format of Table 2 above.
Create a results table based on the expected results of the test using the format of Table 1 above. But, don't actually do the tests yet. This means that the "pass/fail" column will be blank, but all other columns will be filled in.
Bonus (optional): Create a black box testing plan for the requirements in the Lab Part B.3: fill out Tables 4 & 5 from the Lab (black box testing plans) leaving the results blank. This is just a test plan, you'll perform the tests during the lab and finish the table.

Prelab Hand-in Checklist: (90 + 14 pts)

All non-code and non-test plan submissions shall be in a single PDF document.

Part A:

(10 points) Complete Table 1 from part 1.
(10 points) Complete Table 2 from part 1.
(10 points) Complete Table 3 from part 1.
(20 points) Complete Table 4 from part 2.
(Bonus 10 points) Submit your design for the fixed point math sine function in Part 3. The design representation can be any reasonable mixture of mathematical formulas and a flowchart.

Part B:

(40 points -- 20 points for each table) Your completed test plan and results tables (in format of tables 1-2 above) with all test plan information. Please submit this as a PDF file that prints with at least 10 point font (as-printed size) and fits each row on no more than one sheet of paper across. Landscape format is OK to give a little more row width. Do NOT submit in .xls format. We are using PDF files so we do not need to support multiple versions of MS Office.
(Bonus: 4 points) Hand in completed Tables 4 & 5 (black box tests from the Lab description below) except, leave results blank (so this is only a test plan, not a completed report of testing). This is individual work, but you are encouraged to merge these tests with your lab partner's after you hand in your prelab to accomplish more thorough testing.

Refer to the LAB FAQ for more information on lab handin procedures and file type requirements. You MUST follow these procedures or we will not accept your submissions.

Lab 6 - Part A

For this lab, you will establish serial communication with a PC. We have written a simple program which reads a query string from the serial port, looks for the query in a string file, and returns a response string over the serial port. The program uses the following protocol:

Your program must be able to follow this protocol when it sends or receives data from the PC.

In addition to the PC software, you will use an LCD library to display output on the onboard LCD. lcd_lib-1_2.zip contains information about how to use it.

Also, you will use a clock modification library to increase the APS12C128 module bus clock from 2 MHz to 8 MHz. Add the files in modclock.zip to your project.

Try the communication at each baud rate, starting at 300 baud and working up. Record the fastest baud rate that you can successfully communicate at and the slowest baud rate where communication fails (usually with a frame error on the PC). Note that you will have to demo these two speeds to the TA, so if you are doing the part of the lab on a computer other than one in the lab, you must be able to bring the computer with you to lab for the demo. Include the fastest and slowest values in your write up.

Write a subroutine that computes sin(x) for fixed point input values X in radians (4 bits integer; 12 bits fraction; two's complement inputs; same format for outputs). See the corresponding prelab bonus question for more information. Debugging hint: you can generate a large number of automated tests by using the identity sin(X)**2 + cos(X)**2=1 as an oracle to test correct execution. It is also OK to check output values against outputs from a floating point C library. Look at the corresponding writup question before you write this code.

Part A - Demo Checklist: (48 + 20 points)

For the demo, the TA may ask you to use a different string file. The query string will always be your lab number (e.g. "1A" in ASCII characters). Response strings will never be longer than 8 characters.

Lab 6 - Part B:

To write test plans and use various testing techniques to test an existing codebase.

In this lab, you will not write any code. Instead, you will write test plans for code which we will supply to you. The supplied code is the absolute assembly file (with debugging symbols removed). The steps below describe the procedure for loading the code.

Probably you will want to use a spreadsheet program to create these tables, just as they do in industry. But, please turn in Acrobat files as usual, and make sure that the table text is large enough to read (at least 10 point as printed on the page -- not squished down to tiny-type font size!) without requiring us to tape pages together due to wide rows.

Note: If you don't see MultilinkCyclonePro on the menu, to make it appear, do the following
1. Component -> Set Connection
2. Processor HC12, Connection P&E Multilink/Cyclone Pro
3. OK
Now you should see MultilinkCyclonePro as one of the choices on the menu.

After you have handed in your pre-labs, compare your test plans from the pre-lab and merge them to create a better test plan. (You can just use one of your two test-plans as-is if they both look OK to you. We don't care which of the two you pick if they are both good plans.)

A bug identified by your test should be tracked in a bug list as in table 2.3 below. The columns in this table are as follows: The bug # is a unique number assigned to each bug for tracking purposes. Test # should be the test that identified the bug. Transitions should be a list of any transitions that are affected by the bug. Description is a detailed description of the problem (e.g. "Transition Txx causes a transition to state X instead of state Y.").

In this part you will do black box testing on an implementation of the wiper controller similar to the one you wrote for Lab 3. You will develop a test plan that includes an acceptance test to cover every requirement. The wiring from part 1 should work for part 3 as well. PB1 is used to initiate the OFF state, PB2 for INTERMITTENT, PB3 for SLOW, and PB4 for FAST.

The example test shown above tests requirement R6. This is reflected by the X in the traceability table below.

A bug identified by your test should be tracked in a bug list as in table 6 below. The columns in this table are as follows: The bug # is a unique number assigned to each bug for tracking purposes (for example: B1, B2, B3, ...). Test # should be the test that identified the bug. Requirement(s) should be a list of any requirements that are affected by the bug. Description is a detailed description of the problem (e.g. "Transition Txx causes a transition to state X instead of state Y.").

Lab Hand-in Checklist: (127 + 25 pts)

Test plans may be included in your write-up PDF or as an additional PDF file. Test plans must have at least 10 point font (as-printed size) and fit each row on no more than one sheet of paper across. Landscape format is OK to give a little more row width. NOTE: Do NOT submit in .xls format. We are using PDF files so we do not need to support multiple versions of MS Office.