[MUSIC PLAYING]

When you first get started working with an evaluation board like the MSP430 LaunchPad, you first want to do something simple, like making the LED blink. That implies that you understand how to use the development tool, how to initialize the MSP430 and its clocks, and how to send data to the input/output pins. Section 3 and its lab will wrap all that together.

To understand what's going on with the part, we need to understand the system state at reset. When you power up the part, the brownout circuitry holds the device in reset by holding the reset line low until the Vcc, the power that's being applied to the part, is above a certain hysteresis point. It then gives a certain amount of time after that before it actually allows the part to start running. The reset and the non-maskable interrupt pin gets configured as a reset on the device. All of the I/O pins are configured as inputs, so that's a good thing in terms of not shorting anything out on the outside of the part. But it may be a bad thing later on, when we start to look at inputs that are sitting there with nothing applied to them.

The clocks get configured. They probably are not configured in the way that you want them configured. We'll have to go back in and do that.

The peripheral modules and the registers are all initialized. The specifics of that are in the user's guide. Typically, the majority of them are off. That may not be the case in terms of the watchdog timer, since that powers up in active in the watchdog mode.

The status register gets reset. The program counter gets loaded with the address contained at the reset vector location. That's at FFFE in Flash memory. If that reset vector comes back as FFFF-- if you don't know it, FFFF is what a cleared Flash memory, an erased Flash memory, reads. And the assumption will be that the Flash memory is erased. Then the devices gets disabled for minimum power consumption, because this is assuming there's no power-- no code inside the device to run.

So now we can jump off to the software initialization. So after the device comes up from system reset, your software has to initialize the stack pointer, which is usually to the top of RAM, reconfigure the clocks, if it's desired-- and it's almost always desired-- initialize the watchdog timer to the requirements of your application-- in the case of working with the part and debugging, that usually means off-- and then to configure any of the peripheral modules that you want to use in your application.

One of the first things to program and to understand is the clock system on the device. Take a look at the drawing on the right hand side here. You can see that we have three different clocks that are delivered to the device.

The middle one there is the MCLK, the master clock. This is the clock that goes to the central processing unit of the device. Typically that's the part of the device that you will want to use-- run the fastest, and that also uses the most in terms of power in the device.

There are two types of peripherals that you might also have. You might have fast peripherals that need to run at the same speed as the master clock or the CPU. Those are on the submaster clock, or the SMCLK. Those are your high-speed peripherals.

On the top up here are the ACLK. Those are the slower-speed peripherals on the device.

So if we take a look here, we can see that the CPU can be driven by the very low frequency oscillator, the VLO. It can also be driven by the crystal oscillator, if you have one. And it can be driven by the DCO. The DCO is the digitally controlled oscillator on the device.

The ACLK can only be driven by the VLO and the crystal. The SMCLK can only be driven by the DCO.

So what are the capabilities of each of those different clocks? The very low power, very low frequency oscillator, the VLO, goes from 4 to 20 kilohertz, typically in the 12 kilohertz range. 500 nanoamps standby current. 0.5% percent per degree C, and 4% per volt drift. Those are not in the 21x1 devices.

The crystal oscillator has programmable capacitors built into it. It's also a failsafe. Should the crystal break, the oscillator will fault, and you'll switch over to another running device on the part. There's a minimum pulse filter on there as well, and restrictions as far as what crystal that you can actually put on the outside of the device.

The DCO, the digitally controlled oscillator, doesn't require anything connected to it. It does its thing completely internally. 0 to 16 megahertz-- actually, the factory calibration goes from 1 megahertz in some of the devices. Some of the devices have 1 megahertz up to 16 megahertz factory calibration in the Flash, plus and minus 3% tolerance on those.

So on power up, the MCLK and the SMCLK are sourced from the DCO, and those are running about 1.1 megahertz or so. Those haven't been calibrated. The ACLK gets sourced from the low frequency crystal clock, with a internal capacitance of 6 picofarad. If that fails, the ACLK will default to the VLO. So those are the default parameters. We are probably going to set those up just a little bit differently than that.

Value Line parts have a no-crystal-required DCO, or digitally controlled oscillator. The G2xx1, like the 2231 device that came with the 1.4 version of the LaunchPad board and earlier, have the 1 megahertz DCO constants only. Any of the higher frequencies would have to be manually calibrated. For the 2553, they have all four constants shown above, and the calibration constants for the A-to-D converter and the temperature sensor.

So you can see we can run the DCO at a calibrated frequency of 1 megahertz, 8 megahertz, 12 megahertz, or 16 megahertz. If you want to run them at any other possible frequency, you'll have to manually calibrate that and then store those calibration constants.

Programming the calibration on this is fairly straightforward, and there's only a few instructions shown right below in order to do it. The first statement is an if statement. And we're checking to make sure that the calibration constants are not FF.

Well, why do we check to see they're FF? Because when you read an erased Flash memory, it comes back as FF, meaning that somewhere, someone has inadvertently erased your calibration constants. Well, you don't want to flash those into the part. So we're going to double-check that here with a trap. That's probably not what you're going to want to do in production software. Then it's as simple as programming the basic clock control, basic clock system control register 1, with the range and then the DCO control register with the DCO step and modulation with just a couple of instructions.

It's also possible in your software to do a runtime calibration of the VLO. The VLO isn't terrifically capable, in terms of accuracy, but we can calibrate it to the same accuracy as the DCO. In this case, we've run the calibration on the 1 megahertz DCO. We could use one of the timers to time the number of counts that we have on our VLO. So we can do a runtime calibration of the VLO as we're working in our application.

There is a code library on how to do that. Go look up SLAA340 for exactly how to do that. So if you're looking to get crystal-type accuracy from the VLO without having to pay to have a crystal on the device, here's a way for you to minimize the amount of extra parts that you're putting on your board.

The required Vcc varies for the system MCLK that you intend to run the part at. If you intend to run this part at 3.6 volts or 3.3 volts, you can run all the way up to 16 megahertz. But if you want to run it down near 1.8 volts, you can only run the part at 6 megahertz. So you need to match the clock speed that you need with the required Vcc to achieve the very lowest power that you possibly can.

If you're going to be changing the voltage on these devices, these devices don't have an internal low dropout or LDO regulator built in. You would have to provide them with an external one. And that's typically the way that it's done, if you want to get the very best performance of the device over the lifetime of a battery, is to provide a low-cost, external LDO.

If you drop the Vcc below the minimum required for your selected frequency, you're going to get into a region of what we'll call unreliable execution. You probably don't want to go there. All those Value Line parts will operate all the way up to 16 megahertz, if you need them to.

The watchdog timer on the Value Line parts has failsafe operation. If the ACLK or SMCLK fail, the clock source will jump over to the MCLK. If the MCLK is sourced from a crystal and the crystal fails, the MCLK will drop over to the DCO to guarantee that the part will go back in the reset regardless of the failure mechanism that occurs on the clocks, so that you'll be able to guarantee the part-- or your design is not doing something that you don't want it to do.

There's an additional restriction on the watchdog timer clock source, that you cannot disable the active clock source that you've selected for the watchdog timer. The thing that you have to bear in mind is that some of the low-power modes do things like turn off the DCO. They turn off the SMCLK. They may turn off different parts. They may even turn off the VLO.

If you have your watchdog timer sourced from one of those clocks, and you try to go into a low-power mode that turns off that source, you can't do that. The watchdog timer is protected so that it will operate in the way that you programmed it to operate. Now, that can certainly affect your low-power mode performance and your current consumption.

In general, if you have the watchdog timer running, you want it to run off the lowest-power, lowest-cost available clock source that you have on the part. Typically, that's the VLO. That gives you the biggest range of low-power modes that you can go into.

Lab 3 is your first chance to write some real code from a blank page. If you don't understand what an instruction does or what a parameter means, pause the video, look it up in the user's guides that you downloaded in the first section of the workshop. We've tried to provide plenty of explanation in the lab steps, but make sure you take the time to comprehend what's going on, rather than skipping to the solution. Your hard work will be rewarded.

Create a new project by clicking File, New, CCS Project. As before, go ahead and make the selections shown in the workbook. Your dialog may be slightly different than that. And again, if you're using the 2231, make the appropriate choices for that part. Make sure to click Empty Project at the bottom.

The location is MSP430 LaunchPad, Labs, Lab 3, Project. And usually the variant comes up correct. Again, you don't have to have 2553 typed in the left hand window. You're actually making the selection in the right. Make sure you have Empty Project selected, and say Finish.

When the start-up process completes, in the main.c editing window in the middle of the screen, go ahead and replace the existing code with the following code in the workbook. We're about to drop that in. We have the PDF file running on another monitor. Again, if you're using the 2231, use that include header file instead.

The short ifdef structure there corrects an inconsistency between the 2231 and 2553 header files. The 2231 only has a single timer, so it's usually called Timer_A1. The 2553 has two timers, so we have Timer 0A1 and Timer 1A1. This inconsistency should be corrected in future releases and may be by the time you're using this, but it will still work.

So rather than typing all the following code, go ahead and cut and paste this from the workbook PDF. It's possible that you will end up with some formatting issues, and we may as well here. So we'll correct those as we go.

So what we're going to do first, we'll initially start this lab by running the CPU on the VLO. That's the very low frequency oscillator. This is the slowest clock, which runs at about 12 kilohertz.

So we're going to visualize that by blinking the red LED slowly, at a rate of about once every three seconds. We could have let the clock system default to that state, but instead we're going to set it specifically to operate on the VLO. This is going to allow us to change it later in the exercise. We're not going to be using any ACLK clocked peripherals in this lab exercise, but you should recognize that the ACLK is being sourced by the VLO.

So that takes us to step 3. In order to understand the following steps, you need to make sure that you have the following two resources at hand-- either the 2553 or the 2231 header file. You can open that up in the project. We're not going to do that here, but you can open that up here. This file contains all the register and bit definitions for the MSP430 device that we're using.

You should also have the MSP430G2xx user's guide. That's the SLAU144. The latest version is the H version. That document was downloaded in lab 1. This is the user's guide for the entire MSP430 Value Line family. Make sure you open that for viewing. You need to have both those files so you can understand everything that we're doing.

So for debugging purposes, we're now in step 4. It would be handy to stop the watchdog timer. If that's going off all the time, we're going to have to service it, and this is not a good way to debug.

So in main.c, right at "code goes here," go ahead and type, or copy and paste, the instructions shown below in the workbook. That's the watchdog timer control register gets the watchdog timer password plus watchdog timer hold. So that instruction sets the password and the bit to stop the timer.

Look in the header file and the user's guide to understand how it works. I'm serious. Be sure you know how to do this. Don't accept our word for it. This is why we ask you to open up the header file and the document.

So in step 5, we need to configure the LED that's connected to the GP I/O line. The green LED is located on port 1, bit 6, and we need to make this an output. The LED turns on when the output is set to a 1, so we'll clear it to turn the LED off. Leave a line for spacing, and type or cut and paste the next two lines of code-- the P1 dir equals 0x40 and P1 out equals 0.

Again, check the header file in the user's guide to make sure you understand what the concepts are right here. The direction register, by putting a 1 at that place, is telling port 1, bit 6 to be an output. And then we're putting a 0 on that output to make sure that the LED is off.

In step 6, we're going to go ahead and set up the clock system. Enter a line for spacing, and then type the basic clock system control register 3, and then LFXT 1s_2. So that register is one of the basic clock system control registers.

In the user's guide, section 5.3, it tells us that the reset state of the register is 5. Check the bit fields of the register, and notice that these settings are for a 32-kilohertz crystal on the clock input pins with 6-picofarad capacitors and the oscillator fault condition set. Well, this condition would be set anyway, since the crystal wouldn't have enough time to start up before the clock system faulted it. Crystal start-up times can be in the hundreds of milliseconds.

The operator statement-- the operator in the statement logically or's the LFXTS 1s_2, the value of which is 2-0, into the existing bits, resulting in 025H being in the register. This sets bits 4 and 5 to 1-0, enabling the VLO clock. Check it with the documents again.

In step 7, the clock system will force the MCLK, or the master clock, to use the DCO, the digitally controlled oscillator, as its source in the presence of a clock fault. Take a look in the user's guide, section 5.2.7. So we need to do-- we need to clear that fault flag.

On the next line, type IFG1 and equals the not of 0FI-- excuse me, that's OFIFG. So the IFG1 is interrupt flag register 1. A bit field in the register is the oscillator fault interrupt flag, OFIFG. Logically and'ing IFG1 with the not of this will clear bit 1. Check it again in section 5 of the user's guide and the header file.

In step 8, we need to wait about 50 microseconds for the clock fault system to react. Running on the 12-kilohertz VLO, just doing a single instruction will buy us that amount of time. So on the next line, type the underscore bis underscore SR underscore register, SCG1 plus SCG0.

SR means status register. Find the bit definitions-- pause the video, and find the bit definitions for the status register in the user's guide, section 4. Find the definitions for SCG0 and SCG1 in the header file, and notice how they match the bit fields to turn off the system clock generator and the register.

By the way, the underscore before bis defines this as an Assembly-level call from C, which is-- that underscore bis is a bitset operation that's known as an intrinsic.

In step 9, there's a divider in the MCLK clock tree. So we want to go ahead and use divide by 8. So type the following statement on the next line, and look up its meaning.

The operator logically or's the two values with the existing value in the register. Examine these bits in the user's guide and the header field. So you can see the selection of the clock, and then the divider mode in there. Again, take a look in the header file, take a look in the user's guide.

That takes us to step 10. At this point, your code should look like the code in the book. And ours looks pretty much like that.

In the book, I added the comments to make it easier to read and understand. You can enter those if you like, or not, and press ahead. Go ahead and click the Save button on your menu bar to save the file.

In step 11, just one more thing. The last piece of the puzzle is to toggle the green LED. Leave another line for spacing, and enter the following code. This is the while loop.

We already explained the P1 out instruction. That writes to the data register that goes to the GP I/O.

The delay statements used here are built-in intrinsic functions for generating delays. The only parameter that you need is the number of clock cycles that you are entering for that delay. Later on in the workshop, we're going to find out this is not a very good way to generate delays, so don't get used to using it. The while loop repeats the next four lines-- the P1 out, delay, P1 out, delay, forever.

So if you've gone to step 12, your complete code should look like what you see in the workbook, and pretty much what we have here. Great job. Of course, you could have just cut and pasted this from the VLO.txt file in the files folder, but that wouldn't have been that much fun, would it?

So in step 13, go ahead and click the Debug button. After a few moments, the CCS Debug view should open. The program loads automatically. And you should be at the start of main. If this window comes up to Save and Launch, you forgot to click the File Save button. Just say OK.

Monitor your progress in the Console window at the bottom. Once you're up in the Debug window, go ahead and run the code. If everything is working correctly, the green LED on the board should be blinking about once every three seconds.

And we're taking a look. There we go. There, it blinked. And there it blinked. Terrific.

Running the CPU on the other clock sources will speed this up considerably. This will be covered in the remainder of the lab exercise. When you're done, go ahead and halt the code. Click on the Terminate button to stop debugging, and return to the CCS Edit perspective. Make sure your work is saved. We're going to save these off to make sure we save each of the pieces as we go.

Save your work by clicking File, Save As. Select the parent folder. Parent folder is Lab 3. Name your file Lab3A.C, and click OK. Now that's going to add the Lab3A.C editor tab in the window. So close the Lab3A.C editor tab, and then double-click on main.c in the Project Explorer pane to open main.c back up.

The other problem here is Eclipse. When it saw that you dropped the C file into its neighborhood, it decided you wanted that in the project. So Eclipse added that to our project, which was going to cause us grief later on.

Right-click on Lab3A.C in the Project Explorer pane, and there's a couple of ways to do this. You can select Resource Configurations, Exclude From Build, select all, and then say OK.

Next thing we're going to do-- if you have soldered the crystal onto the board, you can do this next portion of the exercise. Otherwise, you may have to go ahead and fast-forward.

So this one's going to run the CPU on the crystal. The crystal frequency is 32 kilohertz, which is about three times faster than the VLO was running. So if we run the previous code using the crystal, the green LED should blink about once per second.

So this part of the lab exercise uses the previous code as a starting point. So we're going to start at the top of the code, and we're going to use both LEDs. Make both LED pins outputs by changing the first P1 dir equals 0x40 to P1 dir 0x41. We also want the red LED to start out on. So change P1 out equals 0 to P1 out equals 0x01.

In step 17, we need to select the external crystal as the low-frequency clock input. So before, we had the basic clock system control register 3 being or'ed with the LFXT 1s_2. We need to change that to 0.

And then we also need to add the xcap_3. Check the user's guide to make sure this is correct. So what we're doing was we're checking-- we're selecting the external crystal and then we're using the xcap_3 parameter to select 12-picofarad load capacitors. The higher load capacitance is necessary for lower-frequency crystals like the 32-kilohertz crystal.

In step 18, in the previous code we cleared the oscillator fault flag and went on with our business, since the clock system is going to default to the VLO anyway. Now we want to make sure that the flag stays clear, meaning that the crystal is up and running. This requires a little loop with a test. So we're going to modify the code that simply cleared the flag, and we're going to write a little piece of code to test the flag and make sure it's cleared.

So replace your code-- your flag clear with the code shown in the workbook and as shown on the screen. So that statement, that while loop, tests the flag in the register. If that fault flag is clear, then we exit the loop.

We need to wait about 50 microseconds after clearing the flag until you test it again. That delay cycles is a lot longer than that. We need that to be that long so that we'll be able to see the red LED is going to flash at the beginning of the code. That way, we know it's been tested. Otherwise, it would flash so quickly that our eyes wouldn't be able to see it at all.

So in step 19, finally we need to add a line of code to turn off the red LED, indicating that the fault test has been passed. So add this new line after the while loop-- the P1 out equals 0.

So since we made a lot of changes to the code and had a chance to make a few errors, check to make sure your code looks like what you see in the workbook and what you see on the video screen right here. Again, you could have cut and pasted all of this from the file XT.txt, but you're here to learn about each one of these pieces.

In step 21, go ahead and click on the Debug button. After a few moments, the CCS Debug view should open. The program should load automatically. And you should be at the start of main. Save your file if you have to.

Take a close look at the LEDs on the LaunchPad, and then run the code. If everything's working correctly, and ours did, the red LED flashes very quickly. The time spent in the delay and waiting for the crystal to start, and then the green LED should blink every second or so. That's about three times the rate that it was blinking before, because we're running at the higher crystal frequency.

When you're done, halt the code by clicking the Suspend button. Then go ahead, click on the Terminate button to stop debugging, and return to the Edit perspective. Go ahead and save your work by clicking File, Save As. And select the parent folder as Lab 3. Name the file Lab3B.C, and click OK.

Again, we'll have to make sure to exclude Lab3B.C from the build, and close the Lab3B editor tab. And then double-click on main.c in the Project Explorer pane.

Excellent. So now we're in the running the CPU on the DCO and the crystal. The slowest frequency that we can run the DCO is about 1 megahertz. This is also the default speed.

So we-- to get started switching the MCLK over to DCO, in most systems, you'll want the ACLK to run either on the VLO or on the crystal. Since the ACLK in our current code is running on the crystal, let's go ahead and leave it at that way, and just turn on and calibrate the DCO, the digitally controlled oscillator.

That takes us to step 24. We could just let the DCO run, but let's go ahead and calibrate it. Right after the code that stops the watchdog timer, add the code that's shown in the workbook.

This is a test in here. Notice the trap. It's possible to erase-- for someone, like a user, to erase segment A of the information Flash memory. Blank Flash memory reads as FF. Plugging FF into the calibration of the DCO would be a real mistake. It's not going to run anything near what you expect it to run. You might want to implement something similar to this in your own fault handling code, but obviously a trap like this would probably not be what you wanted to do in production.

We also need to comment out the line that stops the DCO. On the line that says bis SR register SCG1 plus SCG0, go ahead and comment that out.

Finally, in step 26, we need to make sure that MCLK is sourced by the DCO. So in that instruction that programs the basic clock controls register 2, change the selection from 3 to 0. And we'll leave the divider on there at 8.

Now don't take our word for this. Double-check the bit selection in the user's guide and in the header file to make sure that we did this right. So you can now verify your code with what's in the workbook and what's on the screen here. Again, this code can be found in DCO_XT.txt if you need to compare it or if you're having difficulties.

When you get to that point, go ahead and click on the Debug button. When the CCS Debug view opens, the program loads automatically. And you should be at the start of main.

So in step 29, make sure you're looking closely at the LEDs on the LaunchPad, and go ahead and run the code. If everything's working correctly, the red LED should flash very quickly, and ours did. That's the time spent in that delay and waiting for the crystal to start.

And then the green LED should blink very quickly. The DCO is running at 1 megahertz, which is about 33 times faster than the 32-kilohertz crystal. So the green LED should be blinking at about 30 times per second. And ours looks good.

In step 30, go ahead and click the Terminate button to stop debugging, and return to the Code Composer Edit perspective. Again, save your work by clicking File, Save As. Set the parent folder as Lab 3. This time we're going to name our file Lab3C.C. And click OK.

Make sure you exclude Lab3.C-- or, excuse me, Lab3C.C from the build. Close the Lab3C.C editor tab, and then reopen main.c in the Project Explorer pane.

The previous code that we just showed you was not optimized, but it's very useful for educational purposes, so you see exactly what's going on. Now we'll look at an optimized version. What we're going to do is we're going to delete the code, all of it, from your main.c editor window.

Click anywhere inside the text. Then Control-A, and then delete. What we want to do is copy and paste the code from the Opt_XT.txt file into main.c.

So just go ahead and do a File, Open File. OK, go to Lab 3. File, and we want to put in Opt_XT-- or Opt_XT.txt And that opens. Paste that into main, and you can close the original text file.

Take a close look at this code. You should recognize how everything works. We added a function that consolidates the fault issue, removes the delays, and that tightens up the code quite a bit. Build, load, and run as you did before.

The code should work just like before. If you'd like to test the fault function, you can short the X in and X out pins with a jumper or a pen or something like that before you click the Run button. That would guarantee a fault from the crystal, and the red LED should go ahead and light. You'll have to power cycle the LaunchPad after that to reset the fault.

Go ahead and run the code. And if everything works, you should see it running exactly as before. Then go ahead and click on the Terminate button to stop debugging, and return to the Code Composer Edit perspective. For this one, save your work by doing File, Save As, and save it to Lab3D.C. Make sure you exclude Lab3D.C from your build, and reopen main.c for editing.

If you're rejoining us because you did not put a crystal on your board, welcome back. If you're still working with the crystal, at this point this will be-- that last lab was the last time we'll be using the crystal. So even if you have a crystal on your board, you can just keep going.

So here, the lowest frequency at which we can run the DCO is 1 megahertz. So let's get started switching the MCLK over to the DCO. In most systems, you want the ACLK to run either on the VLO or on the 32-kilohertz crystal. So our ACLK in our current code has it running on the VLO, and we're going to leave it that way, and just turn on and calibrate the DCO.

So that puts us to step 31 in the lab. Double-click on main.c in the Project Explorer pane, if it's not open already. Delete all the code from the file. That's Control-A and delete.

Copy and paste the code from your previously saved Lab3A.C into main. Should know how to do that now. File, Open, find the lab, copy and paste it into main.c. And then you can go ahead and close Lab3A.C.

In step 32, we could just let the DCO run, but let's go ahead and calibrate it. Right after the code that stops the watchdog timer, add the following code that you see in the workbook. And you'll see it added on the screen here.

Now, this is a repeat for you if you were just working with the crystal. Notice the trap. It's possible for the user or someone to inadvertently erase segment A of the information Flash. That's what holds all the calibration constants, including the cal constants for the DCO. Blank Flash memory reads as 0x FF. If you plug FF into the calibration of the DCO, it will not operate as you expect. So you might want to implement some similar kind of fault handling in your system. Probably a trap with an endless while loop is not what you want to do in production code.

The line that stops the DCO-- the bis SR register SCG1 and SCG0-- we need to go ahead and comment that out.

And then in step 34, finally we need to make sure that the MCLK is sourced by the DCO. So change that basic clock control register 2, the selection mode 3, change that to selection mode 0. Double-check that in the user's guide and the header file, and save your work.

So double-check your code against what you see in the workbook at step 35 and what you see on the screen. If you're having problems, this code can be found in DCO_VLO.txt.

In step 36, go ahead and click on the Debug button. The CCS Debug view will open. The program loads automatically. And you should now be at the start of main.

In step 37, go ahead and run the code. If everything's working correctly, the green LED should blink very quickly. With the DCO running at 1 megahertz, that's about 30 times faster than the crystal was running. So the green LED should be blinking at something like 30 times a second. And that looks good.

When you're done, go ahead and halt the code. Click on the Terminate button to stop debugging, and return to the Edit perspective. Save your work by clicking File, Save As. Select the parent folder as Lab 3, and name the file Lab3E.C. Like before, make sure you exclude this file from the build. Close the editor tab for this file, and then reopen main.c for editing in the Project Explorer pane.

Lastly, we're going to run a piece of optimized code that runs the DCO and the VLO. This is a more optimized version of the previous step's code.

Go ahead and delete the code from your main.c editor window, and then open up Opt_VLO.txt, and then copy and paste that code into your main.c. Examine the code, and you should recognize how everything works. A function has been added that consolidates the fault issue, removes the delays, and tightens up the code overall.

Go ahead and build, load, and run it as you did before. The code should work just like it did before. There's no real way to test the fault function here, short of erasing the information segment in that Flash. And let's not do that this time, OK?

So go ahead and run the code. Should run as before. You should see that the LED is toggling at something like 30 hertz.

When you're done, go ahead and click on the Terminate button to stop debugging, and return to the Edit perspective. This time, save your work as Lab3F.C. Then you can go ahead and close the Lab3F.C Editor pane, and make sure you exclude Lab3F.C from the build. When you've done that, go ahead and right-click on Lab 3 in the Project Explorer pane, and select Close Project.