Debug Techinques for HW/SW Systems What's broken, the HW or the SW? Some basic thoughts: -assume that its broken -its not working correctly until proven.

Slides:



Advertisements
Similar presentations
Introduction to Micro-controllers Anurag Dwivedi.
Advertisements

Lab7: Introduction to Arduino
Chung-Ta King National Tsing Hua University
EXTERNAL COMMUNICATIONS DESIGNING AN EXTERNAL 3 BYTE INTERFACE Mark Neil - Microprocessor Course 1 External Memory & I/O.
MICRO-CONTROLLER: A microcontroller is the brain of the robot: These are: 1. Integrated Circuits (ICs) 2. Programmable.
Electronics Principles & Applications Sixth Edition Chapter 10 Troubleshooting (student version) ©2003 Glencoe/McGraw-Hill Charles A. Schuler.
Chapter 7: Introduction to Debugging TECH Prof. Jeff Cheng.
Programming Microcontrollers B. Furman 19MAR2011.
Ch. 1: Scientific Investigations
Complete CompTIA A+ Guide to PCs, 6e Chapter 5: Logical Troubleshooting © 2014 Pearson IT Certification
Landing and Taxi Lights Anti-collision Lights Navigation Lights Cockpit and Cabin Lights Instrument Panel Lights Click on a System Link to Start.
1 Lab2: A/D Converter. 2 This circuit connects a variable voltage to an A/D port on the AVR mcu. Your software running on the AVR mcu will read the digital.
DEBUGGING TECHNIQUES. Wiring Type of wire to use Solid core for breadboard Multiple-strand for flying leads and connections to power supply unit (PSU)
LAB 3 – Review of the Assignment. -- Clarifications Vikram Murali. TA : CSE 140L Prof. CK Cheng.
Programming the ATmega16
Butterfly I/O Ports CS-212 Dick Steflik. I/O for our labs To get data into and out of our Butterfly its a little trickier than using printf and scanf.
Chapter 7 To Err Is Human: An Introduction to Debugging.
AVR Programming CS-212 Dick Steflik. ATmega328P I/O for our labs To get data into and out of our Arduino its a little trickier than using printf and.
2/9/2007EECS150 Lab Lecture #41 Debugging EECS150 Spring2007 – Lab Lecture #4 Laura Pelton Greg Gibeling.
02/10/06EECS150 Lab Lecture #41 Debugging EECS150 Spring 2006 – Lab Lecture #4 Philip Godoy Greg Gibeling.
What to do when you are done. PRINTING WITH PHOTOSHOP.
LSU 11/01/2004System Testing and Debugging1 Programming Unit, Lecture 7.
Embedded Programming and Robotics
Working with Arduino: Lesson #1: Getting Acquainted with the Kit EGN1007.
Arduino Part 1 Topics: Microcontrollers Programming Basics: structure and variables Digital Output Analog to Digital Conversion.
Testbed: Exercises.
Computer Programming and Basic Software Engineering 4. Basic Software Engineering 1 Writing a Good Program 4. Basic Software Engineering.
Chapter 7 To Err Is Human: An Introduction to Debugging.
Embedded Systems Programming 1 ETEE 3285 Topic HW3: Coding, Compiling, Simulating.
Introduction to LabVIEW
1 4-Integrating Peripherals in Embedded Systems (cont.)
I/O Ports CS-280 Dr. Mark L. Hornick 1. CS-280 Dr. Mark L. Hornick 2 Ports are channels from the CPU to external hardware and software Atmega32 has: 4.
MCU: Interrupts and Timers Ganesh Pitchiah. What’s an MCU ?
Program Development Life Cycle (PDLC)
Khaled A. Al-Utaibi  The Push Button  Interfacing Push Buttons to Arduino  Programming Digital Inputs  Working with “Bouncy”
Testing and Debugging Version 1.0. All kinds of things can go wrong when you are developing a program. The compiler discovers syntax errors in your code.
L ILY P AD T RAINING C ENTENNIAL E LEMENTARY 2012 Material by Linz Craig Revision by Sarah Bloms Additional images by Modkit & Adam Meyer.
DEBUGGING. BUG A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected.
Chapter 22 Developer testing Peter J. Lane. Testing can be difficult for developers to follow  Testing’s goal runs counter to the goals of the other.
ECS642U Embedded Systems Cyclic Execution and Polling William Marsh.
AVR Programming: Digital I/O September 10, What is Digital I/O? Digital – A 1 or 0 Input – Data (a voltage) that the microcontroller is reading.
© 2013 The McGraw-Hill Companies, Inc. All rights reserved. McGraw-Hill 10-1 Electronics Principles & Applications Eighth Edition Chapter 10 Troubleshooting.
BMTRY 789 Lecture 11: Debugging Readings – Chapter 10 (3 rd Ed) from “The Little SAS Book” Lab Problems – None Homework Due – None Final Project Presentations.
Timers and Interrupts Anurag Dwivedi. Let Us Revise.
The Information School of the University of Washington 13-Oct-2004cse debug1 Debugging and Troubleshooting INFO/CSE 100, Spring 2005 Fluency in Information.
Warmup – 16FEB2012 This one is for practice. I have paper if you need it. Suppose there are eight, single-pole, single-throw (SPST) switches connected.
Fixing the Defect CEN4072 – Software Testing. From Defect to Failure How a defect becomes a failure: 1. The programmer creates a defect 2. The defect.
Scientific Debugging. Errors in Software Errors are unexpected behaviors or outputs in programs As long as software is developed by humans, it will contain.
David Streader Computer Science Victoria University of Wellington Copyright: David Streader, Victoria University of Wellington Debugging COMP T1.
University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 1 The SCR/A7E Specification Technique — An Example.
Observing the Current System Benefits Can see how the system actually works in practice Can ask people to explain what they are doing – to gain a clear.
Automation and Robotics.  First you select the platform type so that you can use Natural Language PLTW.
Atmega328p Introduction for Digital and PWM Output Brion L Fuller II Robotics Club.
Measurements and Units Chemistry is a quantitative science – How much of this blue powder do I have? – How long is this test tube? – How much liquid does.
Debug Techinques for HW/SW Systems
Arduino Part 1 Topics: Microcontrollers
The first change to your project files that is needed is to change the device to the correct FPGA. This is done by going to the Assignments tab on the.
Debugging Intermittent Issues
Debugging Intermittent Issues
I/O Ports in AVR Sepehr Naimi
Tim Sumner, Imperial College, Rm: 1009, x47552
I/O Ports in AVR Sepehr Naimi
EECS150 Fall 2007 – Lab Lecture #4 Shah Bawany
Decoding and Using a 4x4 Keyboard
Debugging EECS150 Fall Lab Lecture #4 Sarah Swisher
Debugging EECS150 Fall Lab Lecture #4 Sarah Swisher
Lab #1: Getting Started.
Decoding and Using a 4x4 Keyboard
2019 Investing Now Summer Program
Presentation transcript:

Debug Techinques for HW/SW Systems What's broken, the HW or the SW? Some basic thoughts: -assume that its broken -its not working correctly until proven by repeated experiments -never quite trust that it works correctly -assume that a few small bugs may still exist -failure to find bugs usually stems from wrong assumptions -when debugging, prove each assumption correct -don't grasp at straws or take shots in the dart -engineering is not gambling A debugging world view: a zeitgeist of suspicion, tempered by trust in the laws of physics, curiosity dulled only by the determination to stay focused on a single problem, and a zealot's regard for the scientific method. (Jack Gansle)

Debug Techinques for HW/SW Systems What's broken, the HW or the SW? A debugging methodology: (adoped with changes from: Gansel, The Art of Designing Embedded Systems) -make the bug repeatable -observe the behavior, getting information to isolate the apparent bug -create a suspect list (remain rational in this step) -generate a hypothesis to pinpoint the bug -create an experiment to test the hypothesis -fix the bug -test the fix and then everything else You must have good controlability and obserability into the system. -probe with instruments to stimulate and observe the hardware -instrument the software to cause and observe software behavior -this means to both inject stimulus and to observe results -keep notes of your observations Hardware instruments -multimeter, oscilloscope, signal generator Software instruments -LEDs, “printf”, toggle a port pin, watch a timer

Debug Techinques for HW/SW Systems More thoughts about debugging... Sort out what the bug is. Are you looking at the problem or at a symptom? When you find anything you cannot explain, write it down! Is the appearance of the bug correlate with something else? -a new piece of code, new hardware added? -what changed since “last time”? When generating a hypothesis: -ask, “what could cause this behavior?” -don't “shotgun”, use unlikely scenarios (phase of moon, color of pencil) -no wishful thinking A hypothesis is confirmed by observing the hypothesis. Be absolutely sure what you are seeing is what you are looking for. Double check instruments. Once you fix the bug: -prove the problem is gone, replace the bug, see it, then take it away again

Debug Techinques for HW/SW Systems Bugs that mysteriously go away will mysteriously reappear! -Find the problem, or your customer will. Random probing will often give some hints as to what is broken. Just as often you will find weird things that are completely normal and think them to be bugs. -Avoid rabbit trails. Stick to your hypothesis. -Make sure the power is on. -Was the board basically functional? Run a sanity test. -Did you compile the right source file? -“When things are acting funny, measure the amount of funny”. (Bob Pease) -Are any parts warm or hot to the touch? Should they be? -The best troubleshooting tool is between your ears. Thoughts worth considering...

Debug Techinques for HW/SW Systems What's broken, the HW or the SW? If possible, with both new hardware and new software build a little hardware, -write a little software, -test at each step The sure path to frustration is to build all the hardware, write all the software and expect the whole mess to come up and work as expected.

ATMega128 I/O Ports Building/Testing Lab 2 Build the display and then make sure the original board works. Blink some lights! This is also known as the sanity test. It helps you avoid... -programing problems -power supplies that were left off -obviously shorted stuff -101 other stupid things that are easy to do #include int main(){ uint16_t i; DDRB = 0xFF; //port B all outputs while(1){ PORTB = PORTB ^ 0xFF; //flip all bits for (i=0;i<100000;i++) {}; //spin } }//main

ATMega128 I/O Ports Building/Testing Lab 2 Next, try testing to make sure the segments are connected correctly and that the digits are enabled correctly. int main(){ DDRA = 0xFF; //set port A to all outputs DDRB = 0xF0; //set port bits 4-7 B as outputs DDRD = 0x00; //set port D all inputs PORTD = 0xFF; //set port D all pullups PORTA = 0x00; //set port A to all zeros while(1){ PORTB = ~PIND; //push button selects segment } //while } //main

ATMega128 I/O Ports Building/Testing Lab 2 Next, try walking through the segments and digits separately. uint16_t i; //big counter uint8_t k, j; //small counters while(1){ k++; j = (k % 5); //j varies from 0 to 4 PORTB = (j << 4); //walk through the digits PORTA = ~0x01; for (i=0; i<100000; i++){} //A PORTA = ~0x02; for (i=0; i<100000; i++){} //B PORTA = ~0x04; for (i=0; i<100000; i++){} PORTA = ~0x08; for (i=0; i<100000; i++){} PORTA = ~0x10; for (i=0; i<100000; i++){} PORTA = ~0x20; for (i=0; i<100000; i++){} PORTA = ~0x40; for (i=0; i<100000; i++){} //G PORTA = ~0x80; for (i=0; i<100000; i++){} //colon } //while

ATMega128 I/O Ports Building/Testing Lab 2 Debug scenarios (what to do?): -One of the digits are not displaying. -Two digits display at simultaneously. -All the digits display continuously. -Some segments exhibit ghosting when you bring your hand close to the board. -The display is totally blank. -The entire display works one time through then quits.

ATMega128 I/O Ports Remember....