Testing embedded software is more difficult than desktop applications due to limitations of the target hardware. Host-based testing using a scaffold simulator allows testing hardware-independent code early in development. The scaffold simulates hardware functions to enable automated testing. Interrupt routines can be divided into hardware-dependent and independent parts, allowing the test scaffold to call the latter. Laboratory tools like oscilloscopes help debug hardware-software interactions. Assert statements and instruction set simulators also aid debugging.
True stories on the analysis of network activity using Pythondelimitry
The presentation from SPbPython community / PiterPy meetup.
The presentation tells about the problems of analysing the network activity of applications on Linux using Python. The following topics are covered: analysis of network packets, analysis of packet filters, packets crafting using Scapy, analysis of open ports.
True stories on the analysis of network activity using Pythondelimitry
The presentation from SPbPython community / PiterPy meetup.
The presentation tells about the problems of analysing the network activity of applications on Linux using Python. The following topics are covered: analysis of network packets, analysis of packet filters, packets crafting using Scapy, analysis of open ports.
Join this video course on udemy . Click here :
https://www.udemy.com/microcontroller-programming-stm32-timers-pwm-can-bus-protocol/?couponCode=SLIDESHARE
learn STM32 TIMERS, CAN,RTC, PWM,LOW POWER embedded systems and program them using STM32 Device HAL APIs STEP by STEP
>>Welcome to the course which teaches you advanced Micro-controller programming. In this course you are going to learn and master TIMERS, PWM, CAN, RTC, LOW POWER MODES of STM32F4x Micro-controller with step by step guidance. Highly recommended if you are seeking a career in the domain of Embedded software. <<
In this course, you will understand behind the scene working of peripherals with supportive code exercises. I have included various real-time exercises which help you to master every peripheral covered in this course and this course thoroughly covers both theory and practical aspects of TIMERS, PWM, CAN, RTC, LOW POWER MODES of STM32F4x Micro-controller.
VMware’s Nathan Small who works as a Staff Engineer at Global Support Services has put together a great presentation about Advanced Root Cause Analysis. The presentation was designed to give you more insight into how a VMware Technical Support Engineer reviews logs, gathers data and performs in-depth analysis. Nathan is hoping to show you the skills they’re using every day to help determine the root cause for an issue in your environment. With this core knowledge, you will become more self-sufficient within your own environment and be able to diagnose an issue as it occurs rather than after the damage has been done.
Kernel Recipes 2013 - Deciphering OopsiesAnne Nicolas
The Linux kernel is a very complex beast living in millions of households and data centers around the world. Normally, you’re not supposed to notice its presence but when it gets cranky because of something not suiting it, it spits crazy messages called colloquially
oopses and panics.
In this talk, we’re going to try to understand how to read those messages in order to be able to address its complaints so that it can get back to work for us.
Join this video course on udemy . Click here :
https://www.udemy.com/microcontroller-programming-stm32-timers-pwm-can-bus-protocol/?couponCode=SLIDESHARE
learn STM32 TIMERS, CAN,RTC, PWM,LOW POWER embedded systems and program them using STM32 Device HAL APIs STEP by STEP
>>Welcome to the course which teaches you advanced Micro-controller programming. In this course you are going to learn and master TIMERS, PWM, CAN, RTC, LOW POWER MODES of STM32F4x Micro-controller with step by step guidance. Highly recommended if you are seeking a career in the domain of Embedded software. <<
In this course, you will understand behind the scene working of peripherals with supportive code exercises. I have included various real-time exercises which help you to master every peripheral covered in this course and this course thoroughly covers both theory and practical aspects of TIMERS, PWM, CAN, RTC, LOW POWER MODES of STM32F4x Micro-controller.
VMware’s Nathan Small who works as a Staff Engineer at Global Support Services has put together a great presentation about Advanced Root Cause Analysis. The presentation was designed to give you more insight into how a VMware Technical Support Engineer reviews logs, gathers data and performs in-depth analysis. Nathan is hoping to show you the skills they’re using every day to help determine the root cause for an issue in your environment. With this core knowledge, you will become more self-sufficient within your own environment and be able to diagnose an issue as it occurs rather than after the damage has been done.
Kernel Recipes 2013 - Deciphering OopsiesAnne Nicolas
The Linux kernel is a very complex beast living in millions of households and data centers around the world. Normally, you’re not supposed to notice its presence but when it gets cranky because of something not suiting it, it spits crazy messages called colloquially
oopses and panics.
In this talk, we’re going to try to understand how to read those messages in order to be able to address its complaints so that it can get back to work for us.
Lost in Translation: When Industrial Protocol Translation goes Wrong [CONFide...Marco Balduzzi
Protocol gateways are embedded devices used in industrial facilities to integrate legacy equipment such as serial PLCs with modern control networks. Given the importance that these devices play in the operation of manufacturing plants, we conducted a vendor agnostic analysis of the technology behind protocol translation, by identifying new unexplored weaknesses and vulnerabilities. We evaluated five popular gateway products and discovered translation problems that enable potential adversaries to conduct stealthy and difficult-to-detect attacks, for example to arbitrarily disable, or enable a targeted machinery by mean of innocent-looking packets that bypass common ICS firewalls. In this presentation, we share the results of our findings and discuss the impact to the problems that we identified and their potential countermeasures.
OSMC 2014: Server Hardware Monitoring done right | Werner FischerNETWAYS
Server Hardware ist vielfältig - und damit können auch mögliche Probleme auftreten. Für das Monitoring der Serverkomponenten gibt es unterschiedliche Schnittstellen. Die Palette reicht hier von Netzwerkprotokollen wie IPMI und SNMP bis hin zu Checks, die lokal am jeweiligen Server ausgeführt werden müssen (z.B. für RAID-Controller, SMART-Attribute oder GPU-Karten).
Im Vortrag erfahren Sie welche Checks Sie am besten für bestimmte Hardware Komponenten einsetzen und damit zuverlässig zeitnah informiert werden, sobald sich Probleme abzeichnen.
My old security advisories on HMI/SCADA and industrial software released betw...Luigi Auriemma
PDF with all my old security advisories on HMI/SCADA and industrial software released between 2010 and 2012:
Wonderware, GE, ABB, Rockwell, 3S, Siemens, Indusoft, and many others.
ARM Linux Booting Process
One must be wondering How this Embedded Devices come to life? What goes into this devices that will tune to users Commands. We are going to explain about Embedded Arm based devices in general as The ARM architecture is a widely used 32-bit RISC processor architecture. In fact, the ARM family accounts for about 75% of all 32-bit CPUs, and about 90% of all embedded 32-bit CPUs.
Immunizing Image Classifiers Against Localized Adversary Attacksgerogepatton
This paper addresses the vulnerability of deep learning models, particularly convolutional neural networks
(CNN)s, to adversarial attacks and presents a proactive training technique designed to counter them. We
introduce a novel volumization algorithm, which transforms 2D images into 3D volumetric representations.
When combined with 3D convolution and deep curriculum learning optimization (CLO), itsignificantly improves
the immunity of models against localized universal attacks by up to 40%. We evaluate our proposed approach
using contemporary CNN architectures and the modified Canadian Institute for Advanced Research (CIFAR-10
and CIFAR-100) and ImageNet Large Scale Visual Recognition Challenge (ILSVRC12) datasets, showcasing
accuracy improvements over previous techniques. The results indicate that the combination of the volumetric
input and curriculum learning holds significant promise for mitigating adversarial attacks without necessitating
adversary training.
Sachpazis:Terzaghi Bearing Capacity Estimation in simple terms with Calculati...Dr.Costas Sachpazis
Terzaghi's soil bearing capacity theory, developed by Karl Terzaghi, is a fundamental principle in geotechnical engineering used to determine the bearing capacity of shallow foundations. This theory provides a method to calculate the ultimate bearing capacity of soil, which is the maximum load per unit area that the soil can support without undergoing shear failure. The Calculation HTML Code included.
Final project report on grocery store management system..pdfKamal Acharya
In today’s fast-changing business environment, it’s extremely important to be able to respond to client needs in the most effective and timely manner. If your customers wish to see your business online and have instant access to your products or services.
Online Grocery Store is an e-commerce website, which retails various grocery products. This project allows viewing various products available enables registered users to purchase desired products instantly using Paytm, UPI payment processor (Instant Pay) and also can place order by using Cash on Delivery (Pay Later) option. This project provides an easy access to Administrators and Managers to view orders placed using Pay Later and Instant Pay options.
In order to develop an e-commerce website, a number of Technologies must be studied and understood. These include multi-tiered architecture, server and client-side scripting techniques, implementation technologies, programming language (such as PHP, HTML, CSS, JavaScript) and MySQL relational databases. This is a project with the objective to develop a basic website where a consumer is provided with a shopping cart website and also to know about the technologies used to develop such a website.
This document will discuss each of the underlying technologies to create and implement an e- commerce website.
Hybrid optimization of pumped hydro system and solar- Engr. Abdul-Azeez.pdffxintegritypublishin
Advancements in technology unveil a myriad of electrical and electronic breakthroughs geared towards efficiently harnessing limited resources to meet human energy demands. The optimization of hybrid solar PV panels and pumped hydro energy supply systems plays a pivotal role in utilizing natural resources effectively. This initiative not only benefits humanity but also fosters environmental sustainability. The study investigated the design optimization of these hybrid systems, focusing on understanding solar radiation patterns, identifying geographical influences on solar radiation, formulating a mathematical model for system optimization, and determining the optimal configuration of PV panels and pumped hydro storage. Through a comparative analysis approach and eight weeks of data collection, the study addressed key research questions related to solar radiation patterns and optimal system design. The findings highlighted regions with heightened solar radiation levels, showcasing substantial potential for power generation and emphasizing the system's efficiency. Optimizing system design significantly boosted power generation, promoted renewable energy utilization, and enhanced energy storage capacity. The study underscored the benefits of optimizing hybrid solar PV panels and pumped hydro energy supply systems for sustainable energy usage. Optimizing the design of solar PV panels and pumped hydro energy supply systems as examined across diverse climatic conditions in a developing country, not only enhances power generation but also improves the integration of renewable energy sources and boosts energy storage capacities, particularly beneficial for less economically prosperous regions. Additionally, the study provides valuable insights for advancing energy research in economically viable areas. Recommendations included conducting site-specific assessments, utilizing advanced modeling tools, implementing regular maintenance protocols, and enhancing communication among system components.
Industrial Training at Shahjalal Fertilizer Company Limited (SFCL)MdTanvirMahtab2
This presentation is about the working procedure of Shahjalal Fertilizer Company Limited (SFCL). A Govt. owned Company of Bangladesh Chemical Industries Corporation under Ministry of Industries.
Saudi Arabia stands as a titan in the global energy landscape, renowned for its abundant oil and gas resources. It's the largest exporter of petroleum and holds some of the world's most significant reserves. Let's delve into the top 10 oil and gas projects shaping Saudi Arabia's energy future in 2024.
Water scarcity is the lack of fresh water resources to meet the standard water demand. There are two type of water scarcity. One is physical. The other is economic water scarcity.
1. 10.0 DEBUGGING TECHNIQUES
Introduction
Rule of Thumb: Write good, bug-free code from start if you could
Testing/Debugging embedded software is more difficult than application
software
Post-shipment application problems are more tolerable than embedded (real-
time or life-critical) software
2. 10.0 DEBUGGING TECHNIQUES
10.1 Testing on Host Machine
Some reasons why you can’t test (much, if any) on target machine:
Test early (target may not ready or completely stable)
Exercise all code, including exceptions (real situations may be difficult to
exercise)
Develop reusable, repeatable test (difficult to do in target environment, and
likelihood of hitting the same bug is low)
Store test results (target may not even have disk drive to store results)
3. 10.0 DEBUGGING TECHNIQUES
10.1 Testing on Host Machine – 1
Basic Techniques
Fig 10.1 –
Target system on the left: (hardware-indep code, hardware-dep code, hw)
Test system (on host) on the right: (hardware-indep code – same, scaffold – rest)
Scaffold provides (in software) all functionalities and calls to hardware as in the
hardware-dep and hardware components of the target system – more like a simulator
for them!
4.
5. 10.0 DEBUGGING TECHNIQUES
10.1 Testing on Host Machine – 2
Basic Techniques
Fig 10.2 –
Radio.c -- hardware independent code
Radiohw.c – hardware dependent code (only interface to hw: inp() and outp()
supporting vTurnOnTransmitter() and vTurnOffTransmitter() functions
Inp() and outp() must have real hardware code to read/write byte data correctly -
makes testing harder!!
Fig 10.3 –
Replace radiohw.c with scaffold, eliminating the need for inp() and outp() – both
are simulated in software – a program stub!!
6. Figure 10.2 A Poor Plan for Testing
/* File: radio.c */
void vRadioTask (void)
{
.
.
.
!! Complicated code to determine if turning on the radio now
!! is within FCC regulations.
.
.
.
!! More complicated code to decide if turning on the radio now
!! makes sense in our protocol.
If (!! Time to send something on the radio)
{
vTurnOnTransmitter (FREQ_NORMAL);
!! Send data out
vTurnOffRadio ();
}
}
-----------------------------------------------
(continued)
7. Figure 10.2 (continued)
/* File: radiohw.c */
void vTurnOnTransmitter (int iFrequencyValue)
{
BYTE byPower; /* Byte read from device controlling power. */
int i;
/* Turn on main power for the radio. */
disable_interrupts ();
byPower = inp (PWR_CONTROL_ADDR);
byPower |= PWR_CONTROL_RADIO_MAIN;
outp (PWR_CONTROL_ADDR, byPower);
enable_interrupts ();
/* Shift the frequency value out to hardware. */
for (i = 0; i < 16; ++i)
{
/* Send out the lowest bit of iFrequencyValue */
if (iFrequencyValue & 0x0001)
{
/* The data is a binary 1 */
/* Put a '1' on the data line; pulse the clock line. */
outp (FRQ_CONROL, DATA_1 & CLOCK_LOW)
outp (FRQ_CONROL, DATA_1 & CLOCK_HIGH);
}
(continued)
8. Figure 10.2 (continued)
else
{
/* The data is a binary 0 */
/* put a '0' on the data line; pulse the clock line. */
outp (FRQ_CONROL, DATA_0 & CLOCK_LOW)
outp (FRQ_CONROL, DATA_0 & CLOCK_HIGH);
}
/* Shift iFrequencyValue to get the next lowest bit. */
iFrequencyValue >>= 1;
}
/* Turn on the receiver. */
byPower = inp (PWR_CONTROL_ADDR);
byPower |= PWR_CONTROL_RADIO_RECEIVER;
outp (PWR_CONTROL_ADDR, byPower);
enable_interrupts ();
}
void vTurnOffRadio (void)
{
BYTE byPower; /* Byte read from device controlling power. */
/* Turn off main power for the radio. */
disable_interrupts ();
byPower = inp (PWR_CONTROL_ADDR);
byPower &= ~PWR_CONTROL_RADIO_MAIN;
outp (PWR_CONTROL_ADDR, byPower);
enable_interrupts ();
}
------------------------------------------- (continued)
9. Figure 10.2 (continued)
/* File: test.c */
void outp (int Address, BYTE byData)
{
#ifdef LET_USER_SIMULATE_HARDWARE
PRINTF ("program wrote %02x to %04x.", byData, iAddress);
#endif
#ifdef SIMULATE_HARDWARE
!! Remember that software wrote byData to iAddress
!! Update state of simulated hardware.
#endif
}
BYTE inp (int iAddress)
{
int iData;
#ifdef LET_USER_SIMULATE_HARDWARE
PRINTF ("program wrote %02x to %04x. Enter value.",
iAddress);
scanf ("%x", &iData);
#endif
#ifdef SIMULATE_HARDWARE
!! Figure out what the real hardware would return
#endif
return ((BYTE) iData);
}
10. Figure 10.3 Better Plan for Testing
/* File: radio.c */
void vRadioTask (void)
{
.
.
.
!! Complicated code to determine if turning on the radio now
!! is within FCC regulations.
.
.
.
!! More complicated code to decide if turning on the radio now
!! makes sense in our protocol.
If (!! Time to send something on the radio)
{
vTurnOnTransmitter (FREQ_NORMAL);
!! Send data out
vTurnOffRadio ();
}
}
-----------------------------------------------
(continued)
11. Figure 10.3 (continued)
/* File: test.c */
static BOOL fRadionOn;
static int iRadioFrequencyValue;
void vTurnOnTransmitter (int iFrequencyValue)
{
/* Record the state of the radio. */
fRadionOn = TRUE;
iRadioFrequencyValue = iFrequencyValue;
/* Tell the user */
printf ("Radio turned on with frequency %04x", iFrequencyValue);
}
void vTurnOffRadio (void)
{
/* Record the state of the radio. */
fRadioOn = FALSE;
/* Tell the user */
printf ("Radio now off");
}
12. 10.0 DEBUGGING TECHNIQUES
10.1 Testing on Host Machine – 3
Calling Interrupt Routines –
Embedded systems are interrupt-driven, so to test based on interrupts
1) Divide interrupt routines into two components
A) a component that deals with the hardware
B) a component of the routine which deals with the rest of the system
2) To test, structure the routine such that the hardware-dependent component (A) calls
the hardware-independent part (B).
3) Write component B in C-language, so that the test scaffold can call it
E.g., Fig 10.4 –
Hw component (A) is vHandleRxHardware(), which reads characters from the hw
Sw component (B) is vHandleByte, called by A to buffer characters, among others
The test scaffold, vTestMain(), then calls vHandleByte(), to test if the system works
[where vTestMain() pretends to be the hardware sending the chars to vHandleByte()]
13. Figure 10.4 Dividing Interrupt Routines into Two Parts
/* File: serial.c */
#define CR 0x0d
#define SIZEOF_CMD_BUFFER 200
BYTE a_byCommandBuffer[SIZEOF_CMD_BUFFER];
/* Queue to send message to command-handling task. */
extern unsigned long qidCommands;
void interrupt vHandleRxHardware (void)
{
BYTE byChar; /* The character we received */
int iHwError; /* Hardware error, if any */
iHwError = !! Get status from hardware;
if (iHwError == CHARACTER_RXD_OK)
{
/* We received a character; deal with it. */
byChar = !! Read byte from hardware;
vHandleRxByte (byChar);
}
else
!! Deal with hardware error
!! Reset the hardware as necessary.
!! Reset interrupt controller as necessary.
} (continued)
14. Figure 10.4 (continued)
void vHandleRxByte (BYTE byReceived)
{
static BYTE *p_byCommandBufferTail = a_ byCommandBuffer;
extern BYTE *p_byCommandBufferHead;
unsigned long a_ulMessage[4]; /* Message buffer. */
/* Advance the tail pointer and wrap if necessary */
++ p_byCommandBufferTail;
if (p_byCommandBufferTail == &a_ byCommandBuffer
[SIZEOF_CMD_BUFFER])
p_byCommandBufferTail = a_ byCommandBuffer;
/* If the buffer is not full . . . . */
if (p_byCommandBufferTail != p_byCommandBufferHead)
{
/* Store the character in the buffer. */
*p_byCommandBufferTail = byReceived;
/* If we got a carriage return, wake up the command-handling task. */
if (*p_byCommandBufferTail == CR)
{
/* Build the message . . . */
a_ulMessage[0] = MSG_COMMAND_ARRIVED;
a_ulMessage[1] = 0L;
a_ulMessage[2] = 0L;
a_ulMessage[3] = 0L;
(continued)
15. Figure 10.4 (continued)
/* . . . and send it. */
q_send (qidCommands, a_ulMessage);
}
}
else
{
/* Discard the character; move the pointer back. */
if (p_byCommandBufferTail == a_ byCommandBuffer)
p_byCommandBufferTail ==
&a_ byCommandBuffer[SIZEOF_CMD_BUFFER];
-- p_byCommandBufferTail;
}
}
--------------------------------------------
/* File: test.c */
void vTestMain (void)
{
BYTE a_byTestCommand[] = "THUMBS UPx0dSIMON SAYS THUMBS UPx0d";
BYTE *p_by;
.
.
/* Send each of the characters in a_byTestCommand */
p_by = a_byTestCommand;
while (*p_by)
{
/* Send a single character as though received by the interrupt */
vHandleRxByte (*p_by);
/* Go to the next character */
++p_by;
}
.
.
}
16.
17. 10.0 DEBUGGING TECHNIQUES
10.1 Testing on Host Machine – 4
Calling the Timer Interrupt Routine
Design the test scaffold routine to directly call the timer interrupt routine, rather than
other part of the host environment, to avoid interruptions in the scaffold’s timing of
events
This way, the scaffold has control over sequences of events in the test which must
occur within intervals of timer interrupts
Script Files and Output Files
To let the scaffold test the system in some sequence or repeated times, write a script
file (of commands and parameters) to control the test
Parse the script file, test system based on commands/parameters, and direct output –
intermixture of the input-script and output lines – into an output file
The commands in the script cause the scaffold to call routines in the B (sw-indp)
component -- See Fig 10.5 and Fig 10.6 – for the cordless bar-code scanner
18.
19.
20. 10.0 DEBUGGING TECHNIQUES
10.1 Testing on Host Machine – 5
More Advanced Techniques
Making the scaffold automatically control sequence of events – e.g., calling the printer
interrupt many times but in a controlled order to avoid swamping
Making the scaffold automatically queue up requests-to-send output lines, by
automatically controlling the button interrupt routine, which will cause successive
pressing of a button to let the next output line be received from the hardware (the
printer interrupt routine). In this way, the hardware-independent software is controlled
by the scaffold, where the button interrupts serve as a switch
The scaffold may contain multiple instances of the software-independent code, and
the scaffold serves as a controller of the communication between the instances –
where each instance is called by the scaffold when the hardware interrupt occurs
(e.g., the scanner or the cash register). In this way, the scaffold simulates the
hardware (scanner or register) and provides communication services to the software-
independent code instances it calls. – See Fig 10.7
21.
22. 10.0 DEBUGGING TECHNIQUES
10.1 Testing on Host Machine – 6
Objections, Limitations, and Shortcomings
1) Hard to test parts which are truly hardware dependent, until the target system
is operational. Yet, good to test most sw-independent parts on host (see Fig
10.8)
2) Time and effort in writing scaffold – even if huge, it is worthwhile
3) Having the scaffold run on the host and its RTOS – scaffold can run as low
priority task within the RTOS and have nicely integrated testing environment
4) The hard to justify limitations – can’t tell in scaffold until the actual test
Writing to the wrong hardware address – software/hardware interactions
Realistic interrupt latency due to differences in processor speeds (host v. target)
Real interrupts that cause shared-data problems, where real enable/disable is the key
Differences in network addressing, size of data types, data packing schemes –
portability issues
23.
24. 10.0 DEBUGGING TECHNIQUES
10.2 Instruction Set Simulators
Using software to simulate:
The target microprocessor instruction set
The target memory (types - RAM)
The target microprocessor architecture (interconnections and components)
Simulator – must understand the linker/locator Map format, parse and interpret it
Simulator – takes the Map as input, reads the instructions from simulated ROM,
reads/writes from/to simulated registers
Provide a user interface to simulator for I/O, debugging (using, e.g., a macro
language)
25. 10.0 DEBUGGING TECHNIQUES
10.2 Instruction Set Simulators – 1
Capabilities of Simulators:
Collect statistics on # instructions executed, bus cycles for estimating actual times
Easier to test assembly code (for startup software and interrupt routines) in simulator
Easier to test for portability since simulator takes same Map as the target
Other parts, e.g., timers and built-in peripherals, can be tested in the corresponding
simulated versions in the simulated microprocessor architecture
What simulators can’t help:
Simulating and testing ASICs, sensors, actuators, specialized radios (perhaps, in
future systems!!)
Lacking I/O interfaces in simulator to support testing techniques discussed (unless
additional provision is made for I/O to support the scaffold; and scripts to format and
reformat files between the simulator, simulated memory, and the scaffold)
26. 10.0 DEBUGGING TECHNIQUES
10.3 The assert Macro
The assert is used (with a boolean-expression parameter) to check assumptions
If the expression is TRUE nothing happens, if FALSE, a message is printed and
the program crashes
Assert works well in finding bugs early, when testing in the host environment
On failure, assert causes a return to the host operating systems (can’t do on
target, and can’t print such message on target – may not have the display unit)
Assert macro that runs on the target are useful for spotting problems:
1) disabling interrupts and spin in infinite loop – effectively stopping the system
2) turn on some pattern of LEDs or blinking device
3) write special code memory for logic analyzer to read
4) write location of the instruction that cause problem to specific memory for logic
analyzer to read (the Map can help isolate which source code is the culprit!)
5) execute an illegal op or other to stop the system – e.g., using in-circuit emulators
27.
28. 10.0 DEBUGGING TECHNIQUES
10.4 Using Laboratory Tools – Hardware-focused
Lab tools help reveal hard-to-find, very infrequently occurring bugs
Types useful to software engineers:
Voltmeters (measure voltage diff); Ohmmeters (measure resistance/connectedness)
Oscilloscopes (scopes) test events that repeat periodically – monitoring one or two
signals (graph of time v. voltage), triggering mechanism to indicate start of monitoring,
adjust vertical to know ground-signal, used as voltmeter (flat graph at some vertical
relative to ground signal), test if a device/part is working – is graph flat? Is the digital
signal coming through – expecting a quick rising/falling edge (from 0 – VCC or VCC –
0) – if not, scope will show slow rising/falling – indicating loading, bus fight, or other
hardware problem
(See Fig 10.10, Fig 10.11, Fig 10.12, Fig 10.13, Fig 10.14)
29.
30.
31.
32.
33.
34. 10.0 DEBUGGING TECHNIQUES
10.4 Using Laboratory Tools – Hardware-focused - 1
Logic Analyzer
Like storage scopes that (first) capture many signals and displays them
simultaneously
It knows only of VCC and ground voltage levels (displays are like timing diagrams) –
Real scopes display exact voltage (like analog)
Can be used to trigger on-symptom and track back in stored signal to isolate problem
Many signals can be triggered at their low and/or high points and for how long in that
state
Used in Timing or State Mode
35. 10.0 DEBUGGING TECHNIQUES
10.4 Using Laboratory Tools – Hardware-focused – 2
Logic Analyzers in Timing Mode
Find out if an event occurred – did cordless scanner turn on the radio?
Measure how long it took software to respond to an interrupt (e.g., between a button
interrupt signal and activation signal of a responding device – to turn off an bell)
Is the software putting out the right pattern of signals to control a hardware device –
looking back in the captured signal for elapsed time
(See Fig 10.15 on response time)
(See Fig 10.16 on elapsed time)
(See Fig 10.17 – a typical Logic Analyzer with on-screen button, mouse, keyboard,
network adaptor, disk storage for storing configurations/settings, ribbon cables)
36.
37.
38.
39. 10.0 DEBUGGING TECHNIQUES
10.4 Using Laboratory Tools – Hardware-focused – 3
Logic Analyzers in State Mode
Captures signals only on clock-event occurring from the attached hardware
Typical use: instructions read/fetched by microprocessor, data read from or written to
ROM, RAM, or I/O devices
To do so, connect LA to address and data signals and RE/ signal on the ROM (or
RAM)
If triggering is on rising edge of RE/ pin, address and data signals will be captured
Output of LA, called trace, is stored for later analysis – see Fig 10.18
LA can be triggered on unusual event occurrences, then capture signals therefrom –
especially for debugging purposes (e.g., writing data to wrong address, tracking a
rarely occurring bug, filtering signals for select devices or events)
LA can’t capture all signals, e.g., on fetch from caches, registers, un-accessed
memory
40.
41. 10.0 DEBUGGING TECHNIQUES
10.4 Using Laboratory Tools – Hardware-focused – 4
In-Circuit Emulators (ICE)
Replaces target microprocessor in target circuitry (with some engineering)
Has all the capabilities of a software debugger
Maintains trace, similar to that of an LA’s
Has overlay memory to emulate ROM and RAM for a specified range of address within
the ICE (rather than the system’s main ROM or RAM) – facilitates debugging
ICE v. LA
LA’s have better trace and filtering mechanism, and easier to detail and find problems
LA’s run in timing mode
LA’s work with any microprocessor – ICE is microprocessor-specific
LA’s support many but select signals to attach, ICE requires connecting ALL signals
ICE is more invasive
42. 10.0 DEBUGGING TECHNIQUES
10.4 Using Laboratory Tools – Hardware-focused – 5
Hardware Peculiarities that Make Debugging Difficult
Inter-pin distances/intervals for attaching probes – getting smaller
Providing sockets for debugging hardware – simply increases product size
ASIC’s encase signals that are hard to probe and track using LA’s or ICE’s
Use of RISC architectural designs makes it difficult to track when read/write happen in
on-board (microprocessor) caches – different from the external RAM or ROM
Increasingly necessary to know the lab tool chain as it influences the design of product
43. 10. DEBUGGING TECHNIQUES
10.4 Using Laboratory Tools – Hardware-focused – 6
Software-Only Monitors
Monitors allow running an embedded system in the target environment, while
providing debugging interfaces on both the host and target environments
A small portion of the Monitor resides in the target ROM (debugging kernel or
monitor):
The codes receives programs from serial port, network, copies into target’s RAM, and run it
with full debugging capabilities to test/debug the programs
Another portion of monitor resides on host – provides debugging capability and
communicates with the debugging kernel over serial port or network, without hardware
modifications
Compiled, linked (may be located into Map) code is downloaded from the host (by the
portion on the host) to the target RAM or flash (received by the kernel)
Other designs: ROM Emulator interface and JPAG comm. port on the
target processor
(See Fig 10.19)