Status in Teaching Debugging Klaus Kolle ([email protected]) Introducton EDE Background Profile of the EDE engineer Debugging in the Study First Year Second Year Third Year Summary Status in Teaching Debugging Klaus Kolle ([email protected]) Aarhus University School of Engineering ASE 23 October 2013 Status in Teaching Debugging Klaus Kolle ([email protected]) 1
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
• The student will learn to design both analogue anddigital electronics as well as the software necessary forthe device
• The student will learn the basic theories and apply themin projects during the whole study
• First year is mainly focused on teaching the basicmathematics, physics, electronics and software
• Second year is building on the skills learnt in first yearand extending those with more software, digital andanalogue electronics, interaction design, web technologyand control systems theory
• Third year (+ half a year) comprises the electivecourses and the company placement. The 7th semesterconcludes with the final project
• The student will learn to design both analogue anddigital electronics as well as the software necessary forthe device
• The student will learn the basic theories and apply themin projects during the whole study
• First year is mainly focused on teaching the basicmathematics, physics, electronics and software
• Second year is building on the skills learnt in first yearand extending those with more software, digital andanalogue electronics, interaction design, web technologyand control systems theory
• Third year (+ half a year) comprises the electivecourses and the company placement. The 7th semesterconcludes with the final project
• The student will learn to design both analogue anddigital electronics as well as the software necessary forthe device
• The student will learn the basic theories and apply themin projects during the whole study
• First year is mainly focused on teaching the basicmathematics, physics, electronics and software
• Second year is building on the skills learnt in first yearand extending those with more software, digital andanalogue electronics, interaction design, web technologyand control systems theory
• Third year (+ half a year) comprises the electivecourses and the company placement. The 7th semesterconcludes with the final project
• The student will learn to design both analogue anddigital electronics as well as the software necessary forthe device
• The student will learn the basic theories and apply themin projects during the whole study
• First year is mainly focused on teaching the basicmathematics, physics, electronics and software
• Second year is building on the skills learnt in first yearand extending those with more software, digital andanalogue electronics, interaction design, web technologyand control systems theory
• Third year (+ half a year) comprises the electivecourses and the company placement. The 7th semesterconcludes with the final project
• The student will learn to design both analogue anddigital electronics as well as the software necessary forthe device
• The student will learn the basic theories and apply themin projects during the whole study
• First year is mainly focused on teaching the basicmathematics, physics, electronics and software
• Second year is building on the skills learnt in first yearand extending those with more software, digital andanalogue electronics, interaction design, web technologyand control systems theory
• Third year (+ half a year) comprises the electivecourses and the company placement. The 7th semesterconcludes with the final project
• The student will learn to design both analogue anddigital electronics as well as the software necessary forthe device
• The student will learn the basic theories and apply themin projects during the whole study
• First year is mainly focused on teaching the basicmathematics, physics, electronics and software
• Second year is building on the skills learnt in first yearand extending those with more software, digital andanalogue electronics, interaction design, web technologyand control systems theory
• Third year (+ half a year) comprises the electivecourses and the company placement. The 7th semesterconcludes with the final project
• Currently we use the Mbed platform for our projects inthe first year projects - blinking LEDs and printf may bea way to debug the robot over the serial line
• The mBed is a small ”arduino-like” platform with anNXP cortex M3 device used through a cloud compilerwith a huge repository of easy-to-use examples andsource code availible
• This allows students to become familiar with embeddedprogramming without having to worry about devicedrivers, makefiles and other complex issues
• Currently we use the Mbed platform for our projects inthe first year projects - blinking LEDs and printf may bea way to debug the robot over the serial line
• The mBed is a small ”arduino-like” platform with anNXP cortex M3 device used through a cloud compilerwith a huge repository of easy-to-use examples andsource code availible
• This allows students to become familiar with embeddedprogramming without having to worry about devicedrivers, makefiles and other complex issues
• Currently we use the Mbed platform for our projects inthe first year projects - blinking LEDs and printf may bea way to debug the robot over the serial line
• The mBed is a small ”arduino-like” platform with anNXP cortex M3 device used through a cloud compilerwith a huge repository of easy-to-use examples andsource code availible
• This allows students to become familiar with embeddedprogramming without having to worry about devicedrivers, makefiles and other complex issues
• In second year focus is on Systems Engineering, i.e.specification and development of a complete embeddedsystem
• This includes learning to work using a method, howeverthis is out of scope of today’s talk
• Last year’s and this year’s project work is our Zenith 33electric car which participated and will be participatingin the Shell EcoMarathon Race in Rotterdam in May
• last year, we ended up fifth out of approximately thirtycars
• this was a very fine result knowing that the car wasbuilt in a hurry and literally ”thrown” together inRotterdam just before the race
• In second year focus is on Systems Engineering, i.e.specification and development of a complete embeddedsystem
• This includes learning to work using a method, howeverthis is out of scope of today’s talk
• Last year’s and this year’s project work is our Zenith 33electric car which participated and will be participatingin the Shell EcoMarathon Race in Rotterdam in May
• last year, we ended up fifth out of approximately thirtycars
• this was a very fine result knowing that the car wasbuilt in a hurry and literally ”thrown” together inRotterdam just before the race
• In second year focus is on Systems Engineering, i.e.specification and development of a complete embeddedsystem
• This includes learning to work using a method, howeverthis is out of scope of today’s talk
• Last year’s and this year’s project work is our Zenith 33electric car which participated and will be participatingin the Shell EcoMarathon Race in Rotterdam in May
• last year, we ended up fifth out of approximately thirtycars
• this was a very fine result knowing that the car wasbuilt in a hurry and literally ”thrown” together inRotterdam just before the race
• In second year focus is on Systems Engineering, i.e.specification and development of a complete embeddedsystem
• This includes learning to work using a method, howeverthis is out of scope of today’s talk
• Last year’s and this year’s project work is our Zenith 33electric car which participated and will be participatingin the Shell EcoMarathon Race in Rotterdam in May
• last year, we ended up fifth out of approximately thirtycars
• this was a very fine result knowing that the car wasbuilt in a hurry and literally ”thrown” together inRotterdam just before the race
• In second year focus is on Systems Engineering, i.e.specification and development of a complete embeddedsystem
• This includes learning to work using a method, howeverthis is out of scope of today’s talk
• Last year’s and this year’s project work is our Zenith 33electric car which participated and will be participatingin the Shell EcoMarathon Race in Rotterdam in May
• last year, we ended up fifth out of approximately thirtycars
• this was a very fine result knowing that the car wasbuilt in a hurry and literally ”thrown” together inRotterdam just before the race
Subcontractors• The students are divided into sub-teams, in which each
team must supply parts for the complete control systemof the car
• This will train the students in cooperation, negotiationand other teamwork disciplines
• Debugging is also part of getting the interoperationbetween stand-alone devices up and running
• Debugging or inspection of network packages usingWireshark is often introduced as a tool to debugsolutions that communicates over TCP/IP
• The students are introduced to a ”full” embeddedplatform with a (legacy) ARM7 (NXP LPC2478) devicecapable of running either ”bare metal” (OS-less)applications, or has the ability to boot a uClinux(MMU-less). In addition the students will becomefamiliar with writing Linux device drivers, andembedded applications
• Along with this platform, the student have to compileand become familiar with the gcc binutils for the ARMplatform
Subcontractors• The students are divided into sub-teams, in which each
team must supply parts for the complete control systemof the car
• This will train the students in cooperation, negotiationand other teamwork disciplines
• Debugging is also part of getting the interoperationbetween stand-alone devices up and running
• Debugging or inspection of network packages usingWireshark is often introduced as a tool to debugsolutions that communicates over TCP/IP
• The students are introduced to a ”full” embeddedplatform with a (legacy) ARM7 (NXP LPC2478) devicecapable of running either ”bare metal” (OS-less)applications, or has the ability to boot a uClinux(MMU-less). In addition the students will becomefamiliar with writing Linux device drivers, andembedded applications
• Along with this platform, the student have to compileand become familiar with the gcc binutils for the ARMplatform
Subcontractors• The students are divided into sub-teams, in which each
team must supply parts for the complete control systemof the car
• This will train the students in cooperation, negotiationand other teamwork disciplines
• Debugging is also part of getting the interoperationbetween stand-alone devices up and running
• Debugging or inspection of network packages usingWireshark is often introduced as a tool to debugsolutions that communicates over TCP/IP
• The students are introduced to a ”full” embeddedplatform with a (legacy) ARM7 (NXP LPC2478) devicecapable of running either ”bare metal” (OS-less)applications, or has the ability to boot a uClinux(MMU-less). In addition the students will becomefamiliar with writing Linux device drivers, andembedded applications
• Along with this platform, the student have to compileand become familiar with the gcc binutils for the ARMplatform
Subcontractors• The students are divided into sub-teams, in which each
team must supply parts for the complete control systemof the car
• This will train the students in cooperation, negotiationand other teamwork disciplines
• Debugging is also part of getting the interoperationbetween stand-alone devices up and running
• Debugging or inspection of network packages usingWireshark is often introduced as a tool to debugsolutions that communicates over TCP/IP
• The students are introduced to a ”full” embeddedplatform with a (legacy) ARM7 (NXP LPC2478) devicecapable of running either ”bare metal” (OS-less)applications, or has the ability to boot a uClinux(MMU-less). In addition the students will becomefamiliar with writing Linux device drivers, andembedded applications
• Along with this platform, the student have to compileand become familiar with the gcc binutils for the ARMplatform
Subcontractors• The students are divided into sub-teams, in which each
team must supply parts for the complete control systemof the car
• This will train the students in cooperation, negotiationand other teamwork disciplines
• Debugging is also part of getting the interoperationbetween stand-alone devices up and running
• Debugging or inspection of network packages usingWireshark is often introduced as a tool to debugsolutions that communicates over TCP/IP
• The students are introduced to a ”full” embeddedplatform with a (legacy) ARM7 (NXP LPC2478) devicecapable of running either ”bare metal” (OS-less)applications, or has the ability to boot a uClinux(MMU-less). In addition the students will becomefamiliar with writing Linux device drivers, andembedded applications
• Along with this platform, the student have to compileand become familiar with the gcc binutils for the ARMplatform
Subcontractors• The students are divided into sub-teams, in which each
team must supply parts for the complete control systemof the car
• This will train the students in cooperation, negotiationand other teamwork disciplines
• Debugging is also part of getting the interoperationbetween stand-alone devices up and running
• Debugging or inspection of network packages usingWireshark is often introduced as a tool to debugsolutions that communicates over TCP/IP
• The students are introduced to a ”full” embeddedplatform with a (legacy) ARM7 (NXP LPC2478) devicecapable of running either ”bare metal” (OS-less)applications, or has the ability to boot a uClinux(MMU-less). In addition the students will becomefamiliar with writing Linux device drivers, andembedded applications
• Along with this platform, the student have to compileand become familiar with the gcc binutils for the ARMplatform
• In parallel with Mortens more HW oriented approach Iteach the more general principles of debugging
• I’ve taught the art of debugging as part of anothercourse during the past years
• Starting from next summer we will offer a SoftwareEngineering course, which partly is based on thecourse content of the current course
• ”Debugging is twice as hard as writing the code in thefirst place. Therefore, if you write the code as cleverlyas possible, you are, by definition, not smart enough todebug it.” - Brian W. Kernighan.
• In parallel with Mortens more HW oriented approach Iteach the more general principles of debugging
• I’ve taught the art of debugging as part of anothercourse during the past years
• Starting from next summer we will offer a SoftwareEngineering course, which partly is based on thecourse content of the current course
• ”Debugging is twice as hard as writing the code in thefirst place. Therefore, if you write the code as cleverlyas possible, you are, by definition, not smart enough todebug it.” - Brian W. Kernighan.
• In parallel with Mortens more HW oriented approach Iteach the more general principles of debugging
• I’ve taught the art of debugging as part of anothercourse during the past years
• Starting from next summer we will offer a SoftwareEngineering course, which partly is based on thecourse content of the current course
• ”Debugging is twice as hard as writing the code in thefirst place. Therefore, if you write the code as cleverlyas possible, you are, by definition, not smart enough todebug it.” - Brian W. Kernighan.
• In parallel with Mortens more HW oriented approach Iteach the more general principles of debugging
• I’ve taught the art of debugging as part of anothercourse during the past years
• Starting from next summer we will offer a SoftwareEngineering course, which partly is based on thecourse content of the current course
• ”Debugging is twice as hard as writing the code in thefirst place. Therefore, if you write the code as cleverlyas possible, you are, by definition, not smart enough todebug it.” - Brian W. Kernighan.
Debugging a remote embedded system (working on two dif-ferent CPU architectures)
Code optimisationUse the compileroptions
Compilers are good at reporting potential problems
Lint Static analysis of the code - if the compiler does not reportenough potential problems
Profiling Dynamic analysis of the program. Where does the CPUpower go?
SW testEquivalenceclasses
Defining the sufficient test set
BlackBox Testing without knowing the implementationWhiteBox Testing having insight in the designCoverage Did we test all code?Integration Putting it all togetherContinuous inte-gration
Putting together the pieces continuously
Other topics in the course are: The process of creatingexecutables from source code, make, git, virtualisation anddatabases
Where to Develop and Debug• In my opinion it is often much easier to develop and
debug on a well-running development host
• But it requires that stubs are written to mimic themissing HW
• With a deep understanding of the HW, this should beno problem ...
• To quote Morten once again: ”The HW alwaysbehaves a ”bit” different than models (erratasheets, special conditions, interrupts, reset/bootbehaviour, voltage drops, etc...). It is always vitalto verify/profile/investigate the health of the(actual) running system before deployment”
• But of course it is a matter of choice between the timeinvested in developing HW stubs and spending the sameamount of time (or more) in the round-trip time whendeveloping on a low-powered target ...
• But sometimes it is not an option to go on the target asit has not been developed yet
Where to Develop and Debug• In my opinion it is often much easier to develop and
debug on a well-running development host• But it requires that stubs are written to mimic the
missing HW
• With a deep understanding of the HW, this should beno problem ...
• To quote Morten once again: ”The HW alwaysbehaves a ”bit” different than models (erratasheets, special conditions, interrupts, reset/bootbehaviour, voltage drops, etc...). It is always vitalto verify/profile/investigate the health of the(actual) running system before deployment”
• But of course it is a matter of choice between the timeinvested in developing HW stubs and spending the sameamount of time (or more) in the round-trip time whendeveloping on a low-powered target ...
• But sometimes it is not an option to go on the target asit has not been developed yet
Where to Develop and Debug• In my opinion it is often much easier to develop and
debug on a well-running development host• But it requires that stubs are written to mimic the
missing HW• With a deep understanding of the HW, this should be
no problem ...
• To quote Morten once again: ”The HW alwaysbehaves a ”bit” different than models (erratasheets, special conditions, interrupts, reset/bootbehaviour, voltage drops, etc...). It is always vitalto verify/profile/investigate the health of the(actual) running system before deployment”
• But of course it is a matter of choice between the timeinvested in developing HW stubs and spending the sameamount of time (or more) in the round-trip time whendeveloping on a low-powered target ...
• But sometimes it is not an option to go on the target asit has not been developed yet
Where to Develop and Debug• In my opinion it is often much easier to develop and
debug on a well-running development host• But it requires that stubs are written to mimic the
missing HW• With a deep understanding of the HW, this should be
no problem ...• To quote Morten once again: ”The HW always
behaves a ”bit” different than models (erratasheets, special conditions, interrupts, reset/bootbehaviour, voltage drops, etc...). It is always vitalto verify/profile/investigate the health of the(actual) running system before deployment”
• But of course it is a matter of choice between the timeinvested in developing HW stubs and spending the sameamount of time (or more) in the round-trip time whendeveloping on a low-powered target ...
• But sometimes it is not an option to go on the target asit has not been developed yet
Where to Develop and Debug• In my opinion it is often much easier to develop and
debug on a well-running development host• But it requires that stubs are written to mimic the
missing HW• With a deep understanding of the HW, this should be
no problem ...• To quote Morten once again: ”The HW always
behaves a ”bit” different than models (erratasheets, special conditions, interrupts, reset/bootbehaviour, voltage drops, etc...). It is always vitalto verify/profile/investigate the health of the(actual) running system before deployment”
• But of course it is a matter of choice between the timeinvested in developing HW stubs and spending the sameamount of time (or more) in the round-trip time whendeveloping on a low-powered target ...
• But sometimes it is not an option to go on the target asit has not been developed yet
Where to Develop and Debug• In my opinion it is often much easier to develop and
debug on a well-running development host• But it requires that stubs are written to mimic the
missing HW• With a deep understanding of the HW, this should be
no problem ...• To quote Morten once again: ”The HW always
behaves a ”bit” different than models (erratasheets, special conditions, interrupts, reset/bootbehaviour, voltage drops, etc...). It is always vitalto verify/profile/investigate the health of the(actual) running system before deployment”
• But of course it is a matter of choice between the timeinvested in developing HW stubs and spending the sameamount of time (or more) in the round-trip time whendeveloping on a low-powered target ...
• But sometimes it is not an option to go on the target asit has not been developed yet
• To establish the vocabulary I first introduce how adefect infects the code, and that the infectionpropagates to a failure, which is an externallyobservable error
• Classification of bug types can also be useful (Bohrbug,Mandelbug, Heisenbug, Schrodinbug, Phase of theMoon bug, Statistical bug, Noob bug (or Noobug))
• The use of the debug tools and options are refreshed,introduced and applied
• To establish the vocabulary I first introduce how adefect infects the code, and that the infectionpropagates to a failure, which is an externallyobservable error
• Classification of bug types can also be useful (Bohrbug,Mandelbug, Heisenbug, Schrodinbug, Phase of theMoon bug, Statistical bug, Noob bug (or Noobug))
• The use of the debug tools and options are refreshed,introduced and applied
• To establish the vocabulary I first introduce how adefect infects the code, and that the infectionpropagates to a failure, which is an externallyobservable error
• Classification of bug types can also be useful (Bohrbug,Mandelbug, Heisenbug, Schrodinbug, Phase of theMoon bug, Statistical bug, Noob bug (or Noobug))
• The use of the debug tools and options are refreshed,introduced and applied
• To establish the vocabulary I first introduce how adefect infects the code, and that the infectionpropagates to a failure, which is an externallyobservable error
• Classification of bug types can also be useful (Bohrbug,Mandelbug, Heisenbug, Schrodinbug, Phase of theMoon bug, Statistical bug, Noob bug (or Noobug))
• The use of the debug tools and options are refreshed,introduced and applied
• ”Un-systematic debugging is characterised by settingbreakpoints, watches, etc. on suspected places in thecode and then run the program until the breakpoint isreached. Hereafter variables can be inspected.”
• If the developer does not know where to break but justmerely the choice on guesses, it is unsystematic -however it occurs very often, I can observe
• ”Un-systematic debugging is characterised by settingbreakpoints, watches, etc. on suspected places in thecode and then run the program until the breakpoint isreached. Hereafter variables can be inspected.”
• If the developer does not know where to break but justmerely the choice on guesses, it is unsystematic -however it occurs very often, I can observe
Here are seven steps in systematic debugging:T: Track the problem in a databaseR: Reproduce the failureA: Automate and simplify the test caseF: Find possible infection regionsF: Focus on the most likely originsI: Isolate the infection chainC: Correct the defect
• For Systematic Debugging it can be a little hard toestablish an environment and create a realistic situationwithin the relatively short time allocated for eachsubtopic ...
• But, now - next year - when I have more time, I’ll giveit a try
• For Systematic Debugging it can be a little hard toestablish an environment and create a realistic situationwithin the relatively short time allocated for eachsubtopic ...
• But, now - next year - when I have more time, I’ll giveit a try
• This activity is mainly about how we can establish adevelopment and debug environment where we candebug the code, while it executes on the target, butuses a debugger situated more conveniently on thedevelopment host
• So for the students, it is a matter of understanding theproduction of executable code and what the debuggerneeds in order to work separated from the executingcode
• I typically establish a situation where we produces codefor our Linux running on an Embedded Artists LPC2478 (ARM 7) board, while our debugging environmentis situated on the virtual Centos Linux developmenthost, I have provided for the students
• We use a gdb-server on the target
• We use gdb/ddd or Eclipse on the development host
• This activity is mainly about how we can establish adevelopment and debug environment where we candebug the code, while it executes on the target, butuses a debugger situated more conveniently on thedevelopment host
• So for the students, it is a matter of understanding theproduction of executable code and what the debuggerneeds in order to work separated from the executingcode
• I typically establish a situation where we produces codefor our Linux running on an Embedded Artists LPC2478 (ARM 7) board, while our debugging environmentis situated on the virtual Centos Linux developmenthost, I have provided for the students
• We use a gdb-server on the target
• We use gdb/ddd or Eclipse on the development host
• This activity is mainly about how we can establish adevelopment and debug environment where we candebug the code, while it executes on the target, butuses a debugger situated more conveniently on thedevelopment host
• So for the students, it is a matter of understanding theproduction of executable code and what the debuggerneeds in order to work separated from the executingcode
• I typically establish a situation where we produces codefor our Linux running on an Embedded Artists LPC2478 (ARM 7) board, while our debugging environmentis situated on the virtual Centos Linux developmenthost, I have provided for the students
• We use a gdb-server on the target
• We use gdb/ddd or Eclipse on the development host
• This activity is mainly about how we can establish adevelopment and debug environment where we candebug the code, while it executes on the target, butuses a debugger situated more conveniently on thedevelopment host
• So for the students, it is a matter of understanding theproduction of executable code and what the debuggerneeds in order to work separated from the executingcode
• I typically establish a situation where we produces codefor our Linux running on an Embedded Artists LPC2478 (ARM 7) board, while our debugging environmentis situated on the virtual Centos Linux developmenthost, I have provided for the students
• We use a gdb-server on the target
• We use gdb/ddd or Eclipse on the development host
• This activity is mainly about how we can establish adevelopment and debug environment where we candebug the code, while it executes on the target, butuses a debugger situated more conveniently on thedevelopment host
• So for the students, it is a matter of understanding theproduction of executable code and what the debuggerneeds in order to work separated from the executingcode
• I typically establish a situation where we produces codefor our Linux running on an Embedded Artists LPC2478 (ARM 7) board, while our debugging environmentis situated on the virtual Centos Linux developmenthost, I have provided for the students
• We use a gdb-server on the target
• We use gdb/ddd or Eclipse on the development host
• In the elective courses the students mainly apply theirgained knowledge in order to learn and understand newtheory
• My colleague Anders introduces Fuzzy Testing as partof his Advanced Software Design courses (Fuzzy Testingis the art of bombarding the test object with a massiveamount of random data in order to provoke errors)
• If new languages and development environments areintroduced it is expected that the students are able todevelop and debug the programs they are recommendedto construct as part of the learning
• In the elective courses the students mainly apply theirgained knowledge in order to learn and understand newtheory
• My colleague Anders introduces Fuzzy Testing as partof his Advanced Software Design courses (Fuzzy Testingis the art of bombarding the test object with a massiveamount of random data in order to provoke errors)
• If new languages and development environments areintroduced it is expected that the students are able todevelop and debug the programs they are recommendedto construct as part of the learning
• In the elective courses the students mainly apply theirgained knowledge in order to learn and understand newtheory
• My colleague Anders introduces Fuzzy Testing as partof his Advanced Software Design courses (Fuzzy Testingis the art of bombarding the test object with a massiveamount of random data in order to provoke errors)
• If new languages and development environments areintroduced it is expected that the students are able todevelop and debug the programs they are recommendedto construct as part of the learning