Laboratory 1 Manual V1.2 – 7th October 2008 Developing a ...people.ucalgary.ca/~smithmr/2008webs/encm511_08/08Labs/Lab1Man… · This task validates that all the equipment and

Laboratory 1 Manual V1.2 – 7th October 2008 Developing a Blackfin GPIO interface using

an automated embedded testing environment These pages are cut-and-paste from the Lab. 1 web-pages. I have not spent a lot of time reformatting them. I have not checked that the links work correctly from this document – if there are problems in following the links to download code segments, then go to the ENCM511 web site and follow the links there. YOU CAN GET FULL SIZED PICTURES BY ACCESSING LAB 1 ON THE WEB

http://enel.ucalgary.ca/People/Smith/2008webs/encm511_08/08Labs/08Lab1TasksToComplete.htm

Minimum requirements before coming into Laboratory 1 For many of the tasks associated with the Laboratory, code examples are provided to cut down the amount of typing you have to perform during the Laboratory time. You should downloaded any code needed for Laboratory 1 into your ENCM511 directory before coming into the Laboratory. Plan to complete Tasks 1 to 2 (preferably Tasks 1 to 3 or 4) before coming into the Laboratory. You are unlikely to complete the rest of the laboratory in 3 hours otherwise.

1. Testing the development environment -- Check that the audio talk-through program works on your laboratory station T1 - Test CPPTalkthrough. (Task updated for 2008). 2. See the impact of using "debug print" statements on the operation of an embedded system T2 - Debug impact.

In your laboratory report you will need to add a paragraph explaining why "print" and "cout" statements have an impact on "real-time" performance". Get another group to sign off on your demonstration (to them) of the completion of Task 1 and Task 2.

Test last development – TLD 3. Using your standard coding process, develop and test the GPIO interface functions void Initialize_GPIOFlagsASM(void) and unsigned short int ReadGPIOFlagsASM(void); T3 - GPIO Interface. Links are provided to detailed help information on developing the GPIO code..3 Hints - GPIO Interface 4. Use the E-Unit testing frame work to more thoroughly test the GPIO interface functions (TLD -- Test last development approach). Test code can be downloaded from the web. T4 -- GPIO Interface tests

Test driven development - TDD 5. Using a test first development approach (TDD), add tests for the Flash Memory interface void InitFlashASM(void), void InitFlashPortASM(void), void WriteFlashLEDASM( int value), int ReadFlashLEDASM(void). Test code can be downloaded from the web. T5 - Flash Memory Tests 6. Develop the code for the Flash Memory interface InitFlashASM( ), InitFlashPortASM( ), WriteFlashLEDASM( int value), int ReadFlashLEDASM( ) using a TDD approach. Links to hints are provided.T6 - Flash Memory Interface Hints

Functional Testing of Lab. 1 Code -- Demonstrate to T.A. or instructor 7. Echoing the switch positions to the LEDs T7 - Echo switches to LED. Developed in CPP. (80% -- A- grade in the Laboratory to this point)

8. Laboratory design components -- Developing “virtual car” code functionality in CPP using a TDD approach T8 Morse Code. (additional 15% with possible Laboratory bonuses) 9. Does your code really work -- Download and run this audio project which automatically calls all of your Lab. 1 code. Will you have to "recall" your project'? T9 - Does your code really work (additional 5% ) -- CODE-UPDATED

http://enel.ucalgary.ca/People/Smith/2008webs/encm511_08/08Labs/08Lab1Details/08L1task1_TestTalkThrough.htm

Lab. 1 Task 1 -- Test CPP talk-through Code (Updated for 2008) This task validates that all the equipment and software is working correctly at your station

Analog Devices provides a series of example code for their evaluation boards so that people can "quickly get something working". The "Talk-through" example we are going to use in this laboratory is a modified version of the code that is found at C:\Program Files\Analog Devices\VisualDSP 5.0\Blackfin\EZ-KITs\ADSP-BF533\Examples\Audio codec talkthrough\C\TDM

This talk through example shows the programmer how to set-up the audio codecs (A/D and D/A) to capture an audio signal and then play the signal back without changing it (talk-through) . In addition the example shows the programmer how to make use of audio interrupt service routines.

None of this is going to be of a concern for us in this laboratory. We are going to leave all the Analog code alone, and just assume that it works as stated.

We are going to use this code to test that the Blackfin Evaluation board at your Lab. Station works as expected.

You will not have to write any code for this task -- just down load code (C++ and asm files ) and link into a project.

The first thing we need to do is to check that the C++-version of the talk-through code works on our lab-station.

1) If you have not already done so, download ENCM511DirectoryStructure1Sept2008.7z file into your H: directory on your home drive; and then say "Extract here" using 7-zip.

That way everybody in the class will have the correct common directory structure and test driven development environment needed for Assignment 1 and Laboratory 1.

2) Your directory structure should look similar to the picture on the right

• Activate the Analog Devices VDSP development environment, select "Open existing project" and switch to directory H:ENCM511/CPP_Talkthrough_Lab1Task1Task2 inside VDSP. Activate the CPP_Talkthrough_Lab1Task1Task2 project in that directory.

• Build the code using the same procedure as during the Familiarization Laboratory and download the executable to the evaluation board

• Hook up your CD or IPOD output to the CJ2 stereo input. • You can hook up to a streaming radio station and use the output from

the PC

• Hook up your ear-phones to the CJ3 stereo output. • Run the CPP_Talkthrough_Lab1Task1Task2.dxe executable and check that

the talk through program is working.

http://enel.ucalgary.ca/People/Smith/2008webs/encm511_08/08Labs/08Lab1Details/08L1task2_ImpactDebugStatements.htm

Lab. 1 Task 2 -- Impact of Debug operations using standard I/O on the performance of an embedded system (Updated for 2008)

[ Back ] [ Home ] [ Up ] [ Next ]

In the class, we have discussed the impact of using "printf( )" or "cout" statements as part of a code debugging process on real-time embedded system. In this task we will demonstrate the problems with using "print statements" inside real time code:

The Blackfin audio talk-through program is an example of a real time system -- if the "next" audio sample is not available within 1 / 44000 s, the audio signal becomes distorted.

Remove the comment markers (//) from the if and printf( ) in the code for the main.cpp in the project CPP_Talkthrough_Lab1Task1Task2 to include a very simple debug check via a print statement.

Recompile the code and run. The impact on sound quality of a debug operation via a print statement is very obvious. You can try modifying the code to use "cout" operations. By changing the maximum "count" in the SpinWheels( ) code you can cause the debug print statement to execute less often.

Basically, the conclusion I would expect you to reach from this task is -- it is necessary to be able to debug embedded code in a way that does not destroy the performance of the real time system -- that means you must debug without making use of print statements.

You must find a different debugging approach that does not impact on the performance on your code and use a different automated approach that does not require that you look manually at the test results.

In your laboratory write-up, explain the details of why using a print statement for debugging (or any other purpose) is slow and disruptive to a real-time embedded system. What is happening to an embedded system when you use printf( ) statements?

Get another group to sign off in your laboratory report that you have completed the first two tasks of Lab. 1.

http://enel.ucalgary.ca/People/Smith/2008webs/encm511_08/08Labs/08Lab1Details/08L1task3_GPIO_FlagsASM.htm

Lab 1 Task 3 -- General Purpose Input Output interface (Updated for 2008) extern "C" void Initialize_GPIOFlagsASM(void); extern "C" unsigned short int ReadGPIOFlagsASM(void);

WARNING -- SMOKE CAUSING AREA MIS-PROGRAMMING OR MIS-CONNECTION OF WIRES

HAS A REAL POSSIBILITY OF LEADING TO PERMANENT BLACKFIN PROCESSOR DAMAGE

DISCUSSIONS: In the next couple of tasks we need to be able to read the switches on the front panel of the BF533 board. The following is the expected behaviour of the GPIO data register FIO_FLAG_Dwhen you press switches on the front panel of the Blackfin board

• Switch SW1 is connected to GPIO programmable flag bit PF8 -- when SW1 is pressed and FIO_FLAG_D register is read you get the bit pattern 0x0100




• When SW1 and SW4 is pressed at the same time and FIO_FLAG_D register is read you get the bit pattern 0x0900 when FIO_FLAG_D register is read

We need to generate the function void Initialize_GPIOFlagsASM(void) to configure the GPIO interface. Once the PF (programmable flag) interface is working (initialized), then information in the FIO_FLAG_D register will tell us which button (or buttons -- 16 combinations) is being pressed (using the unsigned short int ReadGPIOFlagsASM(void) function). The lecture material Overview of Lab. 1 Slides 15 onwards discusses reading the GPIO flags (building the unsigned short int ReadGPIOFlagsASM(void) function).)

Look at the details in Activating the Blackfin GPIO pins -- Lab. 1.ppt on how to set up the logic Lab and the Blackfin Cables

Laboratory Requirements

1. Close the talkthrough project, you will not need that again till task 9 2. Build a project called Lab1 in your ENCM511Lab1 directory 3. Use your normal coding process to write, debug and demonstrate the code for activating the Blackfin GPIO interface.

Remember that you are sharing the GPIO interface with other threads, so write code that only changes the settings for pins 8, 9, 10 and 11. See Activating the Blackfin GPIO pins -- Lab. 1 for reminders about using the ENCM369 method of using AND and OR instructions for doing this. The ability of using AND and OR instructions is an important skill and will be frequently tested in quizzes and exams.

4. Using the course lecture notes and information from the Blackfin Hardware manual build the routine void Initialize_GPIOFlagsASM(void) to configure the GPIO interface. Place this assembly language function in the file InitializeGPIOFlagsASM.asm in your Lab1directory. NOTE: the T.A. will be using an automated tests to mark your lab. If you call the function something different than Initialize_GPIOFlagsASM(void) and place the code in a file different than InitializeGPIOFlagsASM.asm, the tests will fail and the T.A. will not award you any marks for that part of your lab.

5. Using the course lecture notes and information from the Blackfin Hardware manual build the routine unsigned short int ReadGPIOFlagsASM(void) to read the GPIO interface setting. Place this assembly language function in the file ReadGPIOFlagsASM.asm in your Lab1directory.

When completed your testing, get the T.A. or instructor to sign off that your code is working. Since this is early in the laboratory, you can get another laboratory group (not your closest friends) to sign off this section, meaning, you don't have to wait for a T.A. or instructor

If you need some help to get started in developing these routines -- then follow this link T3 Hints on building the GPIO Interface Before you spend a lot of time debugging you code, I suggest you try Task 4 -- Automated TLD testing of the GPIO interface code. It might make debugging your code alot easier


http://enel.ucalgary.ca/People/Smith/2008webs/encm511_08/08Labs/08Lab1Details/08L1task3_GPIO_FlagsASM_Hints.htm

Lab 1 Task 3 Hints (Updated for 2008) void Initialize_GPIOFlagsASM(void) unsigned short int ReadGPIOFlagsASM(void);


HAS A REAL POSSIBILITY OF LEADING TO PERMANENT BLACKFIN PROCESSOR DAMAGE -- Write the code correctly

Before I started using a TDD process to develop code, the following was roughly my approach to developing a project

1. Build the Lab1 project in the Lab1 directory 2.

Add a Lab1main.cpp and GetBuffer.cpp to the Lab1 project where I imagined that all the code was working as expected. Code would look something like this. Click on thumb-nail for more information. Hint: Right-click on the link and select Save Link As. Now save the file into the Lab1 directory.

3. LIFE CYCLE MODEL USED FOR DEVELOPMENT. Remember the key words I used a "V-shaped" software development life cycle rather than a "waterfall" software development cycle and always provided some basic tests from the very beginning of my coding. I always knew what should happen "in my mind"

4. 5. After doing a code review to catch the typos in the pseudocode design, I now compiled and linked the code. I developed a

basic stub for those functions (just enough code to satisfy the compiler and linker), place in the required files, add into the project. Building stubs has been discussed and demonstrated a number of times in class

6. With the stubs present, I compile and link the code. The code should run, and all the tests that were written inside Lab1main.cpp should fail. If the tests don't fail, then I have written bad tests. There is no code (other than a return statement) in all of the function stubs, so all the tests should fail,

Filling in the Initialize_GPIOFlagsASM( ) stub with the correct information to set the GPIO control register bits to the correct values

Note: Some of the following code is "wrong" with minor typos. These were the mistakes I made when I developed the code the first time. I have deliberately left in the defect code as I want you to think about the code you are typing in, rather than doing a "cut-paste-and-ignore" type of Laboratory. Note: One of the register settings is incorrect. I expect you to check the course notes and hardware manual for the correct GPIO interface settings as part of doing the laboratories. There are 6 register settings that need checking in the manual.

Note: There is a major defect in this code if you compare what is done with what has been stated in the lecture note as needing to be done when initializing the GPIO interface(see Activating the Blackfin GPIO pins -- Lab. 1.ppt). It is a defect in my code as I did not find the logical mistake when running the simple tests provided inside Lab1main.cpp. In previous years the "mistake" remained hidden until Lab. 4 thus making it a DEFECT rather than an ERROR that I found before completing Lab. 1. This year, you find the mistake using the more sophisticated debugging tool E-UNIT which is part of the embedded TDD process research we are undertaking in my Small Microsystems for Improving Life Expectancy (SMILE) laboratory

WARNING: When I was originally developing this code, I was havinga CDAR day (pronounced cedar) -- Can't do anything right day. I keep finding that each time I go "FILE | NEW" and Save As, VDSP keeps letting me save the file into the debug directory rather than Lab. 1 directory. DON'T MAKE THAT MISTAKE -- check the directory before saving the files you write


The information on the programmable flags can be found in the Blackfin Hardware manual -- pages 14-1 to 14-22 SMOKE WARNING -- PROBLEM WITH USING 32-bit read/write instructions WHEN 16-bit read/write operations are needed: Configuring the programmable flags for output when they are actually connected to an input signal, and / or connecting too high voltages when used as an input (e.g. from a signal generator or other voltage / current source) will burn out the pins on the Blackfin processor -- check your code and your wiring.

1. Before you assemble any file, get your laboratory partner to do a code review to make sure that your code syntax and concept is correct. Many simple (and very time wasting) errors can be found by using this "Agile" approach called pair programming. Make a list of your mistakes and look specifically for those that you make the most often rather than (initially) trying to find all errors during a code review. Try to finish Task 3 according to the class notes using your normal code development process. Before spending a lot of time debugging, I suggest you try Task 4 -- Automated TLD testing of the GPIO interface code using the E-UNIT debugging tool.

2. Check the following bit patterns in the manual pages 14-1 to 14-22 to make sure that I have got the patterns around the correct way.

WARNING: This code is changing "all the bits" in the registers and not just "changing bits 8, 9, 10 and 11" as we discussed in the class. Make the corrections to the code to do the job properly. Sometime when you think that certain bits should "obviously" be set to a 1 (true) there is a perfectly logical reason for setting it to a 0 (false). It often depends on the best way to make the processor power up in a "safe" mode.

Modify the your stub code for void Initialize_GPIOFlagsASM(void) as follows

o The FIO_DIR register setting is really critical -- I checked this code 14 zillion times before I coded it and then again after I coded it! We need to have the FIO_DIR register bits PF8, PF9, PF10, PF11 to become inputs (and not outputs). This action is controlled by the flag direction register FIO_DIR. WARNING: if we actually program these lines to act as output, and then connect an input signal to them, we will destroy the Blackfin, so code correctly HINT: If you want to, you can high-light the following text and cut and pasted it into your code. R0 = 0x0000; // Set all bits low -- all input -- why is this "safe" as a start-up" P0.L = lo(FIO_DIR); // Set bottom bits of pointer register P0 P0.H = hi(FIO_DIR; // Set top bits W[P0] = R0; // Set the 16-bits of the FIO_DIR register ssync; // FORCE the processor to do a write to the MMR NOW rather than later

o If the FIO_POLAR register is given the wrong settings, then a 1 level on the input line will read as a 0 and a 0 will read as 1. We need to find this out very quickly -- before moving onto later tasks. This sort of mistake should not turn into a defect -- meaning find it before moving onto the next task. We need to read the FIO_DATA_D register bits PF8, PF9, PF10, PF11 as 1 (active high) when a 1 signal comes in, to the processor, and as a 0 (low) when a 0 signal comes in. This action is controlled by the flag polarity register FIO_POLAR R0 = 0x0F00; // Set bits 8, 9, 10, 11 high, everything else low P0.L = lo(FIO_POLAR); // Set bottom bits of pointer register P0 P0.H = hi(FIO_POLAR); // Set top bits W[P0] = R0; // Set the 16-bits of the FIO_POLAR register ssync; // FORCE the processor to do a write to the MMR NOW rather than later

o If FIO_EDGE register is given the wrong settings, then programmable flag interrupts will not work the way we would expect. But since we will not be using programmable flag interrupts until Lab. 3, then we will not notice any errors in this code for a while, and will think it is working when it is not. This sort of mistake is known as a

"defect"; and since we think the code is "working", any defects will be hard to solve Write the necessary ASM code so that the FIO_EDGE register bits PF8, PF9, PF10, PF11 so that we have level sensitive input signals

o If the FIO_MASKA_D register is set incorrectly, we will find out very quickly. Mask registers are used to turn-on and turn-off the Blackfin interrupts. If we turn the interrupts on by mistake, the processor will report an "unexpected interrupt" problem or crash the moment we press a switch! No programmable flag interrupts can be allowed to occur when pressing the switches. This means that the bits 8, 9, 10, 11 of this register must be set to 0 to block any accidental interrupts. Note that you can read MASKA_D, clear the bits you need, and write back the result. Note that there is an alternative approach using the flag mask interrupt control registers which use a WRITE-1-TO-CLEAR mode of operation.

This means that you write the value 0x1 (b00000001) to the register FIO_MASKA_C to cause bit 0 to clear in the interrupt mask register FIO_MASKA_D without effecting any of the other bits in FIO_MASKA.

This means that you write the value 0x4 b00000100) to the register FIO_MASKA_C to cause bit 2 to clear in the interrupt mask register FIO_MASKA_D without effecting any of the other bits in FIO_MASKA.

With this approach you will need to clear FIO_MASKA_D register using the FIO_MASKA_C register, and clear FIO_MASKB_D register using the FIO_MASKB_C register. Only clear the bits associated with the PF8, PF9, PF10 and PF11 bits. In later laboratories we will need to set interrupts else where.

o FINALLY, as a safety feature, we can tell the processor to ENABLE the flag data register bits PF8, PF9, PF10, PF11 using the Flag Input Enable Register FIO_INEN R0 = 0x0F00; // Set bits 8, 9, 10, 11 high, everything else low P0.L = lo(FIO_INEN); // Set bottom bits of pointer register P0 P0.H = hi(FIO_INEN); // Set top bits W[P0] = R0; // Set the 16-bits of the FIO_INEN register ssync; // FORCE the processor to do a write to the MMR NOW rather than later

3. Before you assemble (using BUILD FILE), do a code review to make sure that your code syntax and concept is correct. Most critical things to check

o Remember that you can smoke the processor if pin direction register is set as output when it should be set as input -- double check the direction register code

o Remember that if you don't enable the correct GPIO pins, then no sensible value will be present when you read the GPIO data register -- double check the enable register code

4. The unsigned short int ReadGPIOFlagsASM(void) routine is straight forward. The lecture material Overview of Lab. 1 Slides 15 onwards discusses reading the GPIO flags (building the unsigned short int ReadGPIOFlagsASM(void) function).)

o Set a data register to point to the GPIO data register o Read the 16-bit GPIO data register into the return register (R?) and make sure that the top 16 bits of the

return register are set to zero o Return from the ReadGPIOFlagsASM( ) routine

5. Run the code -- did it work as expected. Before spending a lot of time debugging, I suggest you try Task 4 -- Automated TLD

testing of the GPIO interface code.

Look at the details from Lab1ActivatingGPIOPins.ppt on how to set up the logic Lab and the Blackfin Cables

http://enel.ucalgary.ca/People/Smith/2008webs/encm511_08/08Labs/08Lab1Details/08L1task4_Test+Init_GPIO_Interface.htm

Lab 1 Task 4 -- Automated testing procedure for the code (Updated for 2008) void Initialize_GPIOFlagsASM(void); unsigned short int ReadGPIOFlagsASM(void);


HAS A REAL POSSIBILITY OF LEADING TO PERMANENT BLACKFIN PROCESSOR DAMAGE

By using tests that examine the condition (state) of the Blackfin hardware after we have programmed it, we can try to minimize problems. One of the problems is that damage may be done (because of incorrect code) while we are doing the tests.

• Before proceeding with Task 4, you need to ensure that your code you developed in Task 3 uses the correct named functions, placed in the correct files in Lab. 1. This is a repeat of the instructions for Task 3

o Develop a project called Lab1 in your ENCM415/Lab1 directory o Using the course lecture notes and information from the Blackfin Hardware manual build the routine extern "C" void

Initialize_GPIOFlagsASM(void) to configure the GPIO interface. Place this "C++" compatible assembly language function in the file InitializeGPIOFlagsASM.asm in your Lab1directory.

o Using the course lecture notes and information from the Blackfin Hardware manual build the routine extern "C" unsigned short int ReadGPIOFlagsASM(void) to read the GPIO interface setting. Place this "C++" compatible assembly language function in the file ReadGPIOFlagsASM.asm in your Lab1directory.

To provide the automated testing using the files I am letting you downloadyou need to build a project in your Lab1Tests directory and convert into a Test Project using the EmbeddedUnit GUI following the procedure from the Familiarization Laboratory and Assignment 1.

1. When the GUI prompts you for "Test Name", enter the name Lab1GPIO 2. Down load the following file into your Lab1Tests directory Lab1GPIO_Test.cpp, this will over write the existing file in your

Lab1Tests directory that was built by the GUI. Use the right-click save as technique for downloading. 3. Select the E-Unit menu option E-Unit Test Connection | Refresh Test Connection 4. Add the files InitializeGPIOFlagsASM.asm and ReadGPIOFlagsASM.asm into the Lab1Tests project under "Files under

Test". Remember, this "adding" adds a link to these files, it does not generate a new copy of the files

Your project structure should now look like this.

Go into Lab1Tests_main.cpp

and change the line

// RunAllTests(showFail, showXFail, showSuccess) failureCount = UnitTest::RunAllTests(true, 0, 0);

so that you can display expected failures and successes

failureCount = UnitTest::RunAllTests(true, true, true);

Build the project and run the first test.

The provided test simply checks that the 50-pin cable is plugged in (SAY WITH ME -- "Insert the cable the correct way (not upside down), push hard till the 'click' is heard – now do it for the other end of the cable") and then check that the logic lab. is switched on and no fuses have blown

You should now modify the tests you used during task3 (from Lab1main.cpp) to run in the E-UNIT testing environment. Try to rewrite your tests before clicking on the thumb-nail picture for more details of what I did.

Hand in this code as part of your laboratory report

Question to answer in your laboratory write-up. When I ran this test, I got the error message "memory leak", indicating that something was wrong with the code. Identify what part of the code is "leaking". Memory leaks, if they occur continually, will destroy your code and cuase "blue screen of death".

Hint: There are two places where we are using memory -- the stack for "buff", and the heap for the "puts" array. Try commenting out those lines and see if the "memory" leak message disappears.

With the E-UNIT testing framework you can do some very detailed testing -- even at the level of "did you perform the number of expected read and write operations within a routine

• This sort of detail is useful for testing loops in C++ (did you go around the loop the correct number of times, not once too many times or once too few?).

• For interfacing problems such as this lab, e.g. did you read and write to the GPIO register values the correct number of times when you were initializing the GPIO interface?

Down load the file Lab1GPIOTestsLowLevel.cpp and add it to your project .

1) With the file Lab1GPIOTestsLowLevel.cpp added to your project, your directory structure should look like this

2) Select the E-Unit menu option E-Unit Test Connection | Refresh Test Connection to make the E-Unit GUI recognize the new tests

You should now be able to build the Lab1Test -- you should expect to have no compile or link errors if your code files, names and location from Task 3 are correct.

6. You can get the E-UNIT GUI to "compile", "load" and "run" the code automatically, saving some steps over using the VDSP interface correctly.

Notice that the tests run faster as the communication between the processor and the PC is handled by a GUI "background communication channel (BTC)" which is much faster than normal prints to the screen.

If you get a failure message (in red), simply click on the failure message and you will get additional information on the test you failed.

Fix your code to pass the tests.

Don't fix the tests to pass the code, unless you are VERY sure that the test is wrong.

• Provide copies of the working code for Task 3 in your laboratory write-up. Follow the coding conventions required for this course

Click on the thumb-nail image to see my code failing as I did not respond to the requests to press switches.

You don't get the "click to jump to failure" capability without having the E-UNIT GUI running. This "jump to

failure" mode is very useful when you take a "test driven development (TDD) approach to developing your code.

If you want to see just the test failures (and not the "very large number of" test successes), go into the file Lab1Tests_main.cpp and change the line

// RunAllTests(showFail, showXFail, showSuccess) failureCount = UnitTest::RunAllTests(true, true, true);

so that you can display expected failures and successes

failureCount = UnitTest::RunAllTests(true, true, false);

to comment out the request to show test successes. Recompile, reload and run the tests again

NOTE: Under some circumstances you can rebuild the project and then run the code but then get the VDSP message "project is out of date -- do you want to rebuild". Say yes to this message. However if, after you rebuild, you get the same message "project is out of date -- do you want to rebuild" again. Just say NO. This problem has been reported to Analog Devices.

http://enel.ucalgary.ca/People/Smith/2008webs/encm511_08/08Labs/08Lab1Details/08L1CommonErrors.htm

Common Errors experienced in the Labs.

Remember to check the cable and logic lab. settings

An issue sometimes found when debugging code in any processor development system

The first couple of times, I ran the test, the code stopped unexpectedly at a "ghost breakpoint" before completing. Ghost breakpoints are breakpoints left over from a previous debug session

If this happens to you -- select DEBUG | RUN again, to cause the code to continue.

Sometimes there seem to be an "infinite" number of ghost breakpoints to clear, especially after you have found many errors in your code.

In this case you need to "clean" the environment.

• (A) Close the GUI; • (B) Exit from VDSP entirely. • (C) Power down the evaluation board

• (D) Power up the evaluation board • (E) Reactivate VDSP • (F) Reactivate the GUI

Common error messages from VDSP (especially when starting up)

Unspecified error: Normally, for me, it means that I have activated 2 VDSP sessions rather than 1.

Solution 1: Close down the second accidentally opened VDSP Blackfin session. Click on the thumb-nail see a typical screen

Notice that there is both a "Analog Devices" and a "VisualDSP" icon in Fig. 1, only the "Analog Devices" in Fig. 2, and multiple icons later in the process

Solution 2: Sometimes you get the "unspecified error" message and there is only one VDSP session "present", especially after horribly crashing the system. In this case, there is a "hidden" VDSP session running.

You need to close the VDSP session you have just started, and then kill the hidden VDSP session via the task manager. Kill the Blackfin "IDDE.EXE" process

NOTE: Under some circumstances you can rebuild the project and then run the code but then get the VDSP message "project is out of date -- do you want to rebuild". Say yes to this message. However if, after you rebuild, you get the same message "project is out of date -- do you want to rebuild" again. Just say NO. This problem has been reported to Analog Devices.

http://enel.ucalgary.ca/People/Smith/2008webs/encm511_08/08Labs/08Lab1Details/08L1task5_Tests_for_flash_memory.htm

Lab 1 Task 5 -- Automated testing procedure for the code (Updated for 2008) Build the stubs for InitFlashASM( ), InitFlashPortASM( ), WriteFlashLEDASM( int value), int ReadFlashLEDASM( ).

[ Back ] [ Home ] [ Up ] [ Next ]

Using a test first development approach (TDD), we need to add tests for the Flash Memory interface void InitFlashASM(void ), void InitFlashPortASM(void ), void WriteFlashLEDASM( int value), int ReadFlashLEDASM(void).

Add the following files to your Lab1Tests Directory and then into the Lab1Tests project

• Lab1FlashTests.cpp

1) Select "Refresh test connection" from the new E-UNIT VDSP menu options

2) Build the tests. The compiler will identify the names of the functions you need to construct.

3) Build the ASM stubs for those functions and place into your Lab1 directory. The following links provide some hints about what must be in the function stubs. Use the "right-click save as" technique we discussed earlier to place these files into your Lab1 directory.

• InitFlashASM( ) in InitFlashASM.asm • InitFlashPortASM( ) in InitFlashPortASM.asm • WriteFlashLEDASM( int value) in WriteFlashLEDASM.asm • int ReadFlashLEDASM( ) in ReadFlashLEDASM.asm

4) Add these files to the Lab1Tests Project -- don't copy them into the Lab1Tests directory (making a second copy in the project); you only want one version of any code.

The screen should now look like this.

5) Build and run the test code. The tests should run, call all the necessary function stubs without crashing with many failures expected as no code is present. In fact, it is a sign of a "bad" test suite and "bad" stubs if any of the tests pass at this point in time.

6) In Task 6, I will provide you with some hints for writing the actual Flash Memory Interface Code.

NEW PROBLEM AROSE FOR ME AT THIS POINT IN TESTING

When I build this project, I got the following error message.

----------------Configuration: Lab1Tests - Debug---------------- Linking... [Error li1040] "C:\Program Files\Analog Devices\VisualDSP 5.0\Blackfin/ldf/adsp-BF533.ldf":459 Out of memory in output section 'L1_code' in processor 'p0' Total of 0x4916 word(s) were not mapped. NOT MAPPED means the compiler can't find a way to use the memory map to place the code into memory Linker finished with 1 error cc3089: fatal error: Link failed Tool failed with exit/exception code: 1. Build was unsuccessful.

You personally may not see this message until a later task in Lab. 1 or perhaps you will not see this error message at all (or during Lab. 3) . It all depends on how large your code is, and how large your code is depends on how your code is written..

This LINKER error message is another indication that we are working with a "real" embedded system. Our program will no longer fit into "internal" memory" of the processor. We now have to learn how to

change the project to (automatically) load our code into "external" memory where there is more room

1) Select Project Options in Lab1Tests

2) Select "Startup code LDF" and select the add "LDF and startup code" option

3) Select Project options again and the "external memory" option. When prompted select "use external memory (SDRAM)

4) Select Project options again and the "system heap" option. When prompted select "customize the system heap" and change "minimum size" to "8" and "kB". (Watch out -- you don't want to set the heap size to 8 bytes by mistake

5) Also set "system stack" to 8 kB

6) Now rebuild the project and the linker will automatically make use of the larger external SDRAM memory space

http://enel.ucalgary.ca/People/Smith/2008webs/encm511_08/08Labs/08Lab1Details/08L1task6_FlashMemoryHints.htm

Lab 1 Task 6 -- Automated testing procedure for the code InitFlashASM( ), InitFlashPortASM( ), WriteFlashLEDASM( int value), int ReadFlashLEDASM( ).

Using a test first development approach (TDD) , we have added the tests for the Flash Memory interface void InitFlashASM(void ), void InitFlashPortASM(void ), void WriteFlashLEDASM( int value), int ReadFlashLEDASM(void).

Now we need to add the code. Here are some screen dumps to provide some hints if you want them

NOTE -- These screen dumps are from "2007". For the updated screen dumps see the lecture Activate LED's Part 3 Recap

InitFlashASM( ) hint

Link to InitFlashASM( ) code

InitFlashPortASM( ) hint

-- fill in the lines marked ?????

WriteFlashLEDASM( int value) hint


Remember that this routine uses a passed in parameter

int ReadFlashLEDASM( ) hint


Code one function at a time, get the tests to work. Obviously some code must be written correctly (InitFlashASM( ) ) before other code will work. However the E-UNIT low level tests will give you confidence that you have written the code in the way you planned, and in a way that meets the Laboratory requirements.

Provide copies of the working code for Task 6 in your laboratory write-up. Follow the coding conventions required for this course

http://enel.ucalgary.ca/People/Smith/2008webs/encm511_08/08Labs/08Lab1Details/08L1task7_Switch_to_LED.htm

Lab 1 Task 7 -- Echo switches to the LEDs

Also look at the details in class notes

1. Close the Lab1Tests project, we have finished with that for now. 2. Open your Lab1 project 3. Edit Lab1main.cpp to use the new routines you have developed -- the following code can be cut and pasted. Do a code review

so that you understand what the code does and be able to generate similar code in quizzes and exams. THERE ARE A COUPLE OF TYPOS LEFT in the code which you should find during your code review. // Prototypes etc void Initialize_GPIOFlagsASM(void); unsigned short int ReadGPIOFlagsASM(void); Initialize_GPIOFlagsASM(void); #define SWITCHES_MASK 0x0F00 // Only GPIO bits 8, 9, 10 and 11 considered #define SW1_PRESSED 0x0100 #define SW2_PRESSED 0x0200 #define SW3_PRESSED 0x0400 // NOTE 0x0400 and not 0x0300 #define SW4_PRESSED 0x0800 // NOTE 0x0800 and not 0x0400

void InitFlashASM(void); void InitFlashPortASM(void); void WriteFlashLEDASM( int value); int ReadFlashLEDASM(void);

InitFlashASM( ); InitFlashPortASM( );

// The "C++" and "C" keyword volatile will be explained in class

volatile unsigned short int switch_result = 0; while (1) { switch_result = ReadGPIOFlagsASM & SWITCHES_MASK; // Read the switches switch_result = switch_result >> 8; // Why do we need to "down-shift by 8" and not by 24? WriteFlashLEDASM(switch_result); }

4. Once the code in 3 is working, modify the code so that you continue echoing the switches to the lights, but can quit the loop, and exit the program properly, when you press all switches at once (about 2 lines of code need to be changed).

Completing this laboratory task is a major milestone

Get a T. A., L. A. or instructor to sign off that you have completed and demonstrated this milestone -- 80% (A- grade) of the laboratory is complete

http://enel.ucalgary.ca/People/Smith/2008webs/encm511_08/08Labs/08Lab1Details/08L1task8StoreKeyValues.htm

Lab 1 Task 8 -- Control radio-controlled "virtual car"

This is the "control" the virtual car part of the laboratory. You need to store 10 sets of directions. and then "play" back the directions on the LED. At a later time, if somebody is interested, we can use these commands to control the car. I'll give you the extra code.

This is your design component -- you do it the way you think best. We discussed the code for this task in the lecture Overview of Lab. 1

Completing this task is a major milestone -- get a T. A., L. A. or instructor to sign off that you have completed and demonstrated this milestone -- 15% of remaining 20% (totally A+ grade) of the laboratory is complete.

Provide a copy of your code for this task in your laboratory report.

BONUS 20% on the Laboratory marks -- use a TDD approach for developing the CPP functions associated with this task. Demonstrate the tests.

http://enel.ucalgary.ca/People/Smith/2008webs/encm511_08/08Labs/08Lab1Details/08L1task9Doesyourcodereallywork.htm

Lab. 1 Task 9 -- Does your code really work?

This is a 5 minute task. Yes, we have done all the tests, but the real test is "does the code work when you add it to existing code" -- integration testing

Go to the directory TalkThroughCode - Lab1Tasks1and2 used in Task 1 T1 - Test CPPTalkthrough. Check the code "still" works -- meaning you can hear the sound.

Close the TalkThroughCodeTask1Task2.dpj project and open the DoesYourCodeReallyWork.dpj project in the same TalkThroughCode - Lab1Tasks1and2 directory.

The difference between the two projects is that in TalkThroughCode - Lab1Tasks1and2.dpj the main.cpp file has a main loop that looks like this

while (1) ;

and in DoesYourCodeReallyWork.dpj this while-loop is replaced with the following code from T7 - Echo switches to LED

void Initialize_GPIOFlagsASM(void); // Initialize the flags unsigned short int ReadGPIOFlagsASM(void);

Initialize_GPIOFlagsASM( ); NEW CODE ADDED

#define SWITCHES_MASK 0x0F00 // Only GPIO bits 8, 9, 10 and 11 considered #define SW1_PRESSED 0x0100 #define SW2_PRESSED 0x0200 #define SW3_PRESSED 0x0400 // NOTE 0x0400 and not 0x0300 #define SW4_PRESSED 0x0800 // NOTE 0x0800 and not 0x0400

void InitFlashASM(void); // Initialize the Flag memory void InitFlashPortASM(void); void WriteFlashLEDASM( int value); int ReadFlashLEDASM(void);

InitFlashASM( ); InitFlashPortASM( );

volatile unsigned short int switch_result = 0;

while (1) { switch_result = ReadGPIOFlagsASM & SWITCHES_MASK; // Read the switches switch_result = switch_result >> 8; // Why do we need to "down-shift by 8" and not by 24? WriteFlashLEDASM(switch_result); }

The compiler and linker, using the details provided by the .dpj file, will pick up all the necessary files from your Lab. 1 directory when you rebuild.

IF YOU CAN RUN THE CODE (hear the sound while pressing the switches and make the lights and switches operate at the same time) with out making any changes to your Lab. 1 code, then I am impressed.

If you can't hear the sound, then try commenting out the line InitFlashASM( );, and if that does not work comment out the line InitFlashPortASM( );

Often the problem is that the sound interface and the LED interface are both operating using the Flash memory interface screwing up each other's settings. Alternatively, a common problem is that when you merge two sets of code -- you forgot to merge an important piece of code, which is what I did the first time I tried this laboratory.

Write a short paragraph in your laboratory report explaining your findings in this task and how you fixed your code to work 5%. (Note, the T.A.s and I know what error to expect, 1 line of code, so don't fake it :-) )

Documents

Laboratory 1 Manual V1.2 – 7th October 2008 Developing a ...people.ucalgary.ca/~smithmr/2008webs/encm511_08/08Labs/Lab1Man… · This task validates that all the equipment and