Get Hardware Fast: Build a test-bench using the MCU in your project
Jon Pearson, Development Tools Marketing Director, Cyp...
feature is not currently used in the design, it gives you a chance to include it in the test-bench and to learn how to use...
Test Driving a Test-Bench
Let's look at an example to see how an inexpensive evaluation kit can be used as a test-bench. T...
Figure 2: PSoC Designer 5.0 Test-bench Implementation



The complete design is shown below in Figure 2 as a screen captur...
Figure 4: USB UART Register Map and Protocol Details



Again, the benefit to your project of using MCU test-benches isn't...
References:

1.           Cypress application note AN2379 at www.cypress.com/design/AN2379.




                          ...
Upcoming SlideShare
Loading in...5
×

Build A Test Bench Using The MCU In Your Project

2,317

Published on

The lack of "real" hardware does not have to delay hardware-based testing of firmware. The same hardware that can be used to evaluate a device has the potential to serve as a test-bench to verify your design. By having those on a project create test-benches to verify design, the quality of the overall firmware your team creates will increase, and the end result will be more reusable on future projects and by other teams.

Published in: Technology
3 Comments
3 Likes
Statistics
Notes
  • I needed to prepare an evaluation board and this article helped me figure it out in a couple of minutes…. Thanks:)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Completely agree with you on the MCU test bench strategy leads ….
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • 'thanks for sharing this info. Hope to use master this in my upcoming project '
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,317
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
3
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "Build A Test Bench Using The MCU In Your Project"

  1. 1. Get Hardware Fast: Build a test-bench using the MCU in your project Jon Pearson, Development Tools Marketing Director, Cypress Semiconductor Corp. Testing the firmware for your MCU project without hardware is about as satisfying as licking pictures in a menu when you are hungry. But the lack of “real” hardware does not have to delay hardware-based testing of firmware. The same hardware that can be used to evaluate a device has the potential to serve as a test-bench to verify your design. If you’ve already acquired an evaluation kit, there is no added cost. Additionally, evaluation kits frequently utilize the same development tools used to create production designs. With the widespread availability of evaluation boards and modules for low-end to high-end devices, almost every engineer can take advantage of this development technique. Early test-bench development can significantly speed the time it takes to integrate the firmware once “real” hardware is available. But this is not the only reason to do this. By having everyone on a project creating test-benches to verify their design, the quality of the overall firmware your team creates will also increase, and the end result will be more reusable on future projects and by other teams. EVMs: Not just for evaluation Most MCU vendors provide suitable general purpose evaluation boards for their products for as little as $69, and even the more complex – i.e., capable – boards can be secured for less than $500. Evaluation boards supply a wide range of hardware capabilities and demo or production-ready software. In order to make a good test-bench, however, a board needs to provide some functionality beyond testing the performance of an MCU for a specific application. Some key characteristics that make an evaluation board a good test-bench include: Generous prototyping area: While I prefer a breadboard with push-in capability, solder holes will work fine. The board should be able to accommodate connection to another MCU – the one you are applying the tests to – or else you will want two boards. One or more pushbutton or DIP switches: These can be used to manually trigger events such as selecting a mode, starting a data capture, injecting a one-off signal, or reseting data collection. One or more potentiometers: These are worth adding to a board if they are missing. Potentiometers can be used as a simple analog stimulus or to dial in a selection to the test-bench or the unit-under-test. For instance, the pushbutton might be used to select the test and the pot can be used to set the level of the test (how much or how long). Several LEDs – I use these to indicate pass/fail or state information from a test, as well as to signal the beginning or end of a test or state. LCD or some other form of display (perhaps OLED): An LCD can provide more information than LEDs during testing. This is especially useful when prompting for action or parameters during a test, as well as for providing instantaneous feedback of key parameters with more granularity. In conjunction with a pushbutton and dial, a very capable menu system can be easily devised. Communications interface to a PC: There is no substitute for simple, straight-forward raw data collection sent to a PC for later analysis. Until recently, this would have always been RS-232 serial communications with transceiver hardware. Since fewer and fewer PCs have serial ports, an evaluation board with USB comes in handy as long as the MCU vendor has tools to help the USB-novice succeed. A viable alternative is to use a USB-to-RS232 adapter, which can be found for less than $20. These are the minimum features needed to support a workable general-purpose test-bench. Most evaluation boards that meet these requirements will undoubtedly include other features that are intended to show off particular features of the specific MCU device. These are helpful since they will help verify those features if you included any of them in your project. Even if the Get Hardware Fast: Build a test-bench using the MCU in your project Page 1 of 6 Published in EDN (http://www.edn.com/article/CA6615612.html) November 2008 [+] Feedback
  2. 2. feature is not currently used in the design, it gives you a chance to include it in the test-bench and to learn how to use it. In the process, you may discover a useful implementation of the feature useful for use in a future design. Depending upon your application, you may find it convenient to have two evaluation boards. One serves as the test-bench that stimulates and monitors the main design in a second device (the device-under-test). This will be especially true when the devices you are interested in are NOT readily available in through-hole packages and/or the prototyping area on the evaluation board is not large enough to support both the circuitry for the test-bench and a device-under-test. It is important that the device-under-test be as identical as possible to the unit you are designing into your end-product with the exception of minor differences such as package type and size. This requirement is not so critical for the test-bench, although the closer the device in the test-bench/evaluation kit resembles the device in the end-product, the more application-specific insight it can provide relevant to the project at hand. The only additional equipment you should have at hand is soldering tools, jumper wires, and PC. Soldering tools are useful for creating a permanent test-bench, compared to temporary breadboarding, which can continued to be used once “real” hardware is available. In many cases, the low cost of an evaluation board makes it cost-effective to continuing using compared to creating a test-bench from scratch. Vendors sometimes provide jumper wires for breadboarding with their evaluation boards but not always in sufficient quantity or variety of lengths. Finally, you’ll need a PC that can run the development tools and interface to the test-bench. If you are using RS-232 on your test-bench and your PC does not have a serial port, remember to add a USB-to-RS-232 adapter cable and to confirm its capabilities. Practice Makes Faster The primary benefit of a test-bench is to speed project design by allowing team members to begin integrating their firmware using the board as a reasonable hardware surrogate. Given access to the hardware/system requirements, they can construct a subsystem suitable for independently testing each subsection of a design. Thus, as soon as functions are designed, they can be implemented, tested, and verified in a “real world” environment with equivalent operating conditions. If everyone on the team does this, they can begin integrating some (or all) of the functional areas together and run them on test-benches. Then, when the “real” hardware arrives, final integration is much smoother. Using a test-bench also provides a buffer against hardware delays. Since hardware is usually later than expected, this also pushes out initially testing. With a test-bench, however, software developers can utilize the delay in hardware availability to ferret out issues in the meantime. In this way, the design schedule can be better preserved, despite any delays. Additionally, when hardware does arrive and problems arise, there is a level of confidence and capability developed in the team to quickly isolate the cause of the problem because of early familiarity with the system. In many cases, the problem will likely be in hardware since software has been rigorously tested at this point. Finally, since “real” hardware tends to be in short supply when it does arrive, evaluation board test-benches enable more team members will be able to work concurrently. Such work in parallel results in faster overall development in terms of calendar deadlines. Another consequence of test-benching is increased quality of the project at hand, not just because the firmware is being tested “early and often”, but because in working with the MCU to develop test-benches, team members must stretch themselves outside the bounds of their immediate feature or problem. Designing a test-bench forces engineers to think about how the function should behave under all circumstances. Engineers must approach design from a preventative perspective with a test- bench, rather than taking a symptomatic approach to repair problems as often happens when a system is completed before any real testing occurs. Working early on with this mindset strengthens the individual's skills with the MCU. These additional skills become a critical success factor to the project the moment a problem arises (i.e. at some point in most every project) because now the designers have a greater array of tools at their disposal. More ideas from more people coming from more directions, all because each had their own test-bench to “play” with. Finally, if some of the same rigor is put on the test-bench developments as is for the rest of the project – that is, documenting the work and maintaining it in a configuration management system – the team will have developed a set of test-benches that a formal test group can take advantage of. These base test-benches can be leveraged into better formal system-level tests faster. Also, since the functions from one designer can be developed and tested with its own test-bench, separate from other designers, the team has built a library of well-tested functions that can be combined in many different ways to speed a new/different project into production. And as before, these regression tests and hardware to run them are available to use immediately on new projects before any “real” hardware is available. Get Hardware Fast: Build a test-bench using the MCU in your project Page 2 of 6 Published in EDN (http://www.edn.com/article/CA6615612.html) November 2008 [+] Feedback
  3. 3. Test Driving a Test-Bench Let's look at an example to see how an inexpensive evaluation kit can be used as a test-bench. The evaluation kit I chose is TM CY3214-PSoCEvalUSB, which is pictured in Figure 1. The evaluation board contains a Cypress PSoC device CY8C24094, a special emulation version of silicon that can emulate any member of the CY8C24x94 family of devices. Many evaluation boards include similarly flexible devices so that a single evaluation board can serve across a wider range of devices. These devices can be programmed like production silicon or can be used with an in-circuit emulator to debug/emulate an application program. This is convenient and not uncommon for an evaluation kit. For this example, I developed a test-bench for a voltage- sequencing-and-monitoring application. Figure 1: Evaluation Kit CY3214-PSoCEvalUSB plus CY3210-27xxx Note that within families of MCUs, sometimes the differences between devices are the amount of memory available and peripheral choice, with all other features identical. Depending upon the portfolio a vendor offers, you’ll have the option of selecting a device for your test-bench with more features than you may be using in the device under test. For example, you might want to select a test-bench MCU that supports USB even if your device under test does not in order to facilitate data transfer. In this voltage-sequencing-and-monitoring example, the system has six voltage rails and six enables, one associated with each rail (for more information about this common MCU function, see reference 1). The requirements for the test-bench generally depends on what you need the system to do. For this example, I built my test-bench with nine analog-to-digital converter (ADC) inputs, three digital-to-analog converter (DAC) outputs, a two-line LCD display, seven digital inputs, and a full- speed USB interface. Six of the ADC inputs are used for the six voltage rails and six of the digital inputs for the six enables. These are the monitors for this voltage-sequencing-and-monitoring project. The three DACs will be used for voltage signal injection and as stimulus for test sequences. The other three ADC inputs are to monitor the actual voltage produced by the DACs. One line of the LCD will display the state of the enables while the other line will display one of the six voltage rails, selected by the pushbutton switch which is tied to the seventh digital input. The USB interface will let us access more simultaneous data from the test-bench and log it to a PC. As assisting in software design continues to become more and more a part of selling hardware, MCU evaluation kits are often designed to provide a fast out-of-box experience to demonstrate a device’s capabilities. As a result, development tools often include wizards, configuration GUIs, and graphical design tools that enable engineers to quickly build designs that would have taken days or weeks of manual learning the development tools just a few years ago. These tools also speed development of test-bench software and interfaces. Additionally, code developed for a test-bench often teaches a device’s capabilities to engineers as well as provides some code that can be in designs. These same tools that facilitate fast evaluation can be used to quickly create a basic test-bench as described above in a matter of hours, using high-level system functions that include all of the control and routing firmware needed to implement the features we desire. Demo or application code can be used as well to provide core functionality blocks, such as stitching inputs and outputs together or creating a custom set of data registers that a USB virtual comm port driver can access using HyperTerm on a PC. Get Hardware Fast: Build a test-bench using the MCU in your project Page 3 of 6 Published in EDN (http://www.edn.com/article/CA6615612.html) November 2008 [+] Feedback
  4. 4. Figure 2: PSoC Designer 5.0 Test-bench Implementation The complete design is shown below in Figure 2 as a screen capture and is divided into three parts. On the left is the catalog of high level functions, called drivers. On the right is the datasheet associated with one of these drivers, specifically the pushbutton. And in the middle we see our test-bench, with six voltage rail inputs (VRailxxx), three stimulus voltage outputs (StimxOut), the enable digital input (Enables), the LCD line 1 (EnablesDisplay), and the LCD line 2 (VoltDisplay which selects a label and Voltage that selects an actual reading to display). The item called USB interface is a drop-in configuration and protocol that even generates an appropriate protocol that works with a Microsoft Windows standard USBSER.SYS driver. More detail on this driver is shown in figure 3 below, called USB UART. Figure 4 shows the actual register map ordering and more details of the USB UART command protocol. Figure 3: USB UART Properties and Datasheet Get Hardware Fast: Build a test-bench using the MCU in your project Page 4 of 6 Published in EDN (http://www.edn.com/article/CA6615612.html) November 2008 [+] Feedback
  5. 5. Figure 4: USB UART Register Map and Protocol Details Again, the benefit to your project of using MCU test-benches isn't just the testing but the knowledge gained by using the MCU in a different way than the project requires. Not only does getting started become easier, deeper learning comes from continuing from this starting point to branch out into more specialized test-benches. With quick-start development tools, it is still possible to continue to dig deeper and customize the project, or simply learn more about the MCU and the development tools by looking beneath the surface of the high-level abstraction to all of the automatically generated code are available to designers. While every new project has risk, using an MCU test-bench strategy is an effective way to reduce the risk of late hardware while speeding up hardware/software integration time. Hardware cost is low with the benefits going well beyond simply providing better testing, enabling formal verification early in the design cycle that increases the quality of the end product without negatively impacting the design schedule. These are all capabilities the team needs to learn at some anyway, and the more each team member knows about how the MCU works, the development environment works, and their own implementation works, the better the design, this time and in the future. Get Hardware Fast: Build a test-bench using the MCU in your project Page 5 of 6 Published in EDN (http://www.edn.com/article/CA6615612.html) November 2008 [+] Feedback
  6. 6. References: 1. Cypress application note AN2379 at www.cypress.com/design/AN2379. Cypress Semiconductor 198 Champion Court San Jose, CA 95134-1709 Phone: 408-943-2600 Fax: 408-943-4730 http://www.cypress.com © Cypress Semiconductor Corporation, 2007. The information contained herein is subject to change without notice. Cypress Semiconductor Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. PSoC Designer™, Programmable System-on-Chip™, and PSoC Express™ are trademarks and PSoC® is a registered trademark of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are property of the respective corporations. This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source Code except as specified above is prohibited without the express written permission of Cypress. Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. Use may be limited by and subject to the applicable Cypress software license agreement. Get Hardware Fast: Build a test-bench using the MCU in your project Page 6 of 6 Published in EDN (http://www.edn.com/article/CA6615612.html) November 2008 [+] Feedback

×