Integration testing is a crucial step in the software development process, ensuring that different modules or components of a system work together as expected. Unlike unit testing, which tests individual components in isolation, integration testing focuses on the interaction between these components.
In this tutorial, we’ll break down integration testing for beginners, explaining its importance, types, methods, and providing examples to help you get started.
What is Integration Testing?
Integration testing is a type of software testing that focuses on verifying how different modules or components of a system interact and integrate with each other. It is typically conducted after unit tests (which test individual components) and before system testing (which tests the complete system).
The goal is to identify issues that might arise when different parts of a system interact, such as problems with data flow, incorrect interfaces, or communication failures between modules.
Why is Integration Testing Important?
Integration testing helps detect issues such as:
Data mismatches: Problems that occur when data is passed between modules, like incorrect formatting or missing fields.
Incorrect interfaces: Bugs that appear when two modules do not interact correctly, due to incorrect assumptions about the interface or behavior.
Communication issues: Problems in communication between software components, especially in distributed systems.
Without integration testing, you might miss bugs that only appear when different components of a system work together.
Types of Integration Testing
1. Big Bang Integration Testing
In Big Bang testing, all the modules or components are integrated together at once, and the system is tested as a whole. This approach can be risky because it might be difficult to isolate the root cause of any issues.
Pros: Simple to set up initially. Cons: Hard to debug, and identifying the source of a problem is challenging.
2. Incremental Integration Testing
In incremental integration testing, modules are integrated one by one, and testing is done after each integration step. This allows you to catch issues early, making the debugging process easier.
Types of Incremental Integration Testing:
Top-Down Integration: Testing starts with the top-level modules (or components) and works down to the lower-level modules.
Advantages: You can test high-level functionality early.
Disadvantages: Lower-level modules may be stubbed out (replaced with placeholders) initially.
Bottom-Up Integration: Testing starts with the lower-level modules and works upwards.
Advantages: Lower-level modules are fully tested first.
Disadvantages: Higher-level modules may require stubs for testing.
Sandwich Integration: A mix of top-down and bottom-up approaches, where both high-level and low-level modules are tested simultaneously, working towards each other.
Integration Testing Process
Here’s a step-by-step guide to the integration testing process:
Step 1: Understand the Modules and Their Interfaces
Before starting integration testing, you must understand how the components/modules interact with each other. This includes knowing:
Input and Output: What data each module takes in and produces.
APIs: How the modules communicate (e.g., function calls, REST APIs, database queries).
Dependencies: Any external systems or modules that your component depends on.
Step 2: Create Integration Test Cases
Integration test cases are based on the interactions between components. These cases should test the following:
Data flow: Does data flow correctly between components?
Error handling: Does the system handle errors from other components gracefully?
Performance: Do the modules work efficiently when integrated?
Step 3: Set Up the Environment
Ensure that the necessary dependencies (e.g., databases, APIs, external services) are available. For example, if you’re testing a web application, you might need to set up a server and a database.
Step 4: Execute the Tests
Run the integration tests and monitor how the modules interact. Log all the test results for analysis.
Step 5: Analyze Results and Debug
Once tests are executed, check the logs and test results to identify any issues. If there are failures, isolate the module causing the issue and fix it.
Step 6: Iterate and Improve
Integration testing is an iterative process. After fixing identified issues, rerun tests to confirm that the issues are resolved and no new problems have been introduced.
Common Challenges in Integration Testing
Complexity: Large systems with many components can be challenging to test because of the number of interactions between modules.
Dependency Issues: Some modules may depend on external services or systems, making it hard to test in isolation.
Timing and Synchronization: When testing distributed systems or real-time applications, ensuring proper synchronization between components can be difficult.
Best Practices for Integration Testing
1. Test Early and Often
Perform integration testing early in the development cycle and frequently as new components are added or modified. This helps to catch issues before they become too complex or expensive to fix.
2. Automate Tests
Automating integration tests can speed up the process, especially for large systems. Use tools like Jenkins, Travis CI, or GitLab CI for continuous integration testing.
3. Isolate Components Where Possible
If possible, isolate components using mock services or stubs for external dependencies. This helps you focus on testing the integration of the modules without worrying about external factors.
4. Use Version Control
Ensure that all code is properly version-controlled. This makes it easier to revert to previous versions if integration issues arise.
5. Test for Edge Cases
Don’t just test the happy path (the ideal case). Test how the system behaves under unusual or error-prone conditions, such as invalid data, network failures, or unexpected input.
Tools for Integration Testing
Here are some popular tools to help with integration testing:
JUnit (Java): A widely used framework for writing and running tests in Java.
Selenium: A tool for automating web browsers, often used for integration testing of web applications.
Postman: A tool for testing APIs, particularly useful for integration testing involving web services.
SoapUI: A tool for testing SOAP and REST APIs, useful for integration testing of web services.
Jenkins: A popular tool for automating integration testing in continuous integration pipelines.
Conclusion
Integration testing is a vital step in ensuring the overall functionality and reliability of a system. By focusing on how individual components interact, integration testing helps identify and resolve issues before they impact the end user.
Following best practices, using the right tools, and applying systematic approaches to integration testing will ensure your software performs as expected in real-world environments.
Start by understanding how your system’s components interact, write meaningful test cases, and iteratively test your system to catch any integration-related bugs.
FAQ for Integration Testing Basics
1. What is Integration Testing?
Integration testing is the phase in software testing where individual components or systems are combined and tested as a group. The goal is to ensure that the modules or components work together as expected.
2. Why is Integration Testing Important?
Integration testing is crucial because it identifies issues in the interaction between integrated units. While unit testing verifies individual components, integration testing ensures that the combined modules function correctly as a whole.
3. What Are the Types of Integration Testing?
There are several approaches to integration testing:
Big Bang Integration Testing: All components are integrated at once and tested together.
Incremental Integration Testing: Components are integrated one by one and tested in small parts. It can be:
Top-down: Testing starts with the top-level modules and progressively moves downward.
Bottom-up: Testing starts with the lower-level modules and moves upward.
Sandwich/Hybrid: A combination of top-down and bottom-up.
4. What Are the Key Objectives of Integration Testing?
To verify data flow between components.
To identify problems that occur when multiple components interact.
To detect interface issues.
To ensure the overall system performs as expected.
5. How Is Integration Testing Different from Unit Testing?
Unit Testing focuses on testing individual units or components of the system in isolation.
Integration Testing checks the interaction between different units or components after they’ve been integrated.
6. What Are the Common Challenges in Integration Testing?
Complexity: With many components to test, managing and tracking tests becomes difficult.
Environment Setup: Setting up the integrated system or environment may be time-consuming.
Data Issues: Ensuring accurate data flows between components can be tricky.
Interface Compatibility: Verifying that the interfaces between components work correctly.
7. What Tools Are Used for Integration Testing?
Common tools for integration testing include:
JUnit (for Java)
TestNG (for Java)
Postman (for API testing)
SoapUI (for SOAP and REST APIs)
Selenium (for web application testing)
Mockito (for mocking objects in unit and integration testing)
8. What Is a Test Harness in Integration Testing?
A test harness is a set of tools, scripts, and procedures used to automate the testing of an integrated system. It helps in setting up the environment, invoking tests, and validating results.
9. How Do You Write Test Cases for Integration Testing?
Integration test cases should focus on:
Data Flow Validation: Ensuring data is passed correctly between components.
Functional Testing: Ensuring that combined components work together to perform the intended functionality.
Error Handling: Ensuring the system handles errors correctly when interactions between modules fail.
10. What is Stubbing and Mocking in Integration Testing?
Stubbing: Replacing a module or function with a controlled response to isolate the components under test.
Mocking: Similar to stubbing, but involves creating a fake object to simulate the behavior of a component or service.
11. How Do You Handle Dependencies in Integration Testing?
During integration testing, external dependencies (like databases or services) should be either mocked or simulated if they are unavailable. This ensures that the integration test remains focused on the functionality of the integrated components rather than the external services.
12. When Should Integration Testing Be Performed?
Integration testing should be performed after individual components have passed unit testing and before system testing or user acceptance testing (UAT).
13. What Are Common Integration Testing Techniques?
Interface Testing: Validating that communication between integrated units follows the expected protocol.
Data Integrity Testing: Ensuring that data flows correctly between components and is transformed as expected.
Error Path Testing: Verifying that errors are handled correctly when a component fails or behaves unexpectedly.
14. How Do You Measure the Effectiveness of Integration Testing?
Effectiveness can be measured by:
The number of defects found during integration.
The level of coverage (i.e., how many integration scenarios were tested).
The time taken to resolve defects found during integration testing.
15. What Is the Role of Continuous Integration (CI) in Integration Testing?
In Continuous Integration (CI), integration tests are automatically executed whenever a new piece of code is pushed to the repository. This helps in catching issues early and ensures that newly integrated components don’t break the system.
You can also Visit other tutorials of Embedded Prep
System testing is an essential phase in software development where the entire system is tested as a whole to ensure it functions as intended. It focuses on validating both the functional and non-functional requirements of a system. This tutorial will guide you through the basics of system testing, its objectives, types, and how to perform it effectively.
What is System Testing?
System testing is the process of testing the complete and integrated software system to verify that it meets the specified requirements. It checks if the system behaves as expected in all scenarios, considering both functional (features, functionality) and non-functional (performance, security) requirements.
Key Objectives of System Testing
Verify functionality: Ensure the system performs all the intended functions correctly.
Detect defects: Identify any bugs or issues that may cause the system to behave unexpectedly.
Ensure reliability: Check if the system operates consistently under various conditions.
Assess performance: Evaluate if the system performs well under different loads and stress conditions.
Validate compatibility: Ensure the system works on different hardware, operating systems, and browsers (if applicable).
Types of System Testing
System testing can be broken down into several types, each focusing on a specific aspect of the system:
Functional Testing: Validates that the system behaves according to the functional specifications.
Example: Testing whether the user login feature works as expected.
Performance Testing: Assesses how the system performs under different workloads.
Example: Testing how the system responds when multiple users log in at the same time.
Security Testing: Ensures that the system is secure from threats and unauthorized access.
Example: Testing for SQL injection vulnerabilities in a web application.
Usability Testing: Validates the ease of use and user-friendliness of the system.
Example: Testing if a user can easily navigate through a website without confusion.
Compatibility Testing: Checks if the system works correctly across different environments (e.g., OS, browsers, hardware).
Example: Testing if a web application works on Chrome, Firefox, and Edge.
Stress Testing: Tests the system under extreme conditions, such as high traffic or heavy resource usage.
Example: Testing how a website behaves when receiving thousands of requests in a short period.
Regression Testing: Ensures that new changes or bug fixes have not negatively impacted the existing system.
Example: After fixing a bug in the payment feature, test the entire system to ensure nothing else is broken.
Steps in System Testing
Understand the System Requirements
Review the functional and non-functional requirements of the system. These will be the basis for your test cases.
Develop Test Plan
A test plan outlines the scope, objectives, and approach for system testing. It also includes the resources, schedule, and risk assessment.
Design Test Cases
Based on the system requirements, create test cases that cover all aspects of the system.
Test cases should include:
Test description
Expected results
Steps to execute the test
Input data
Expected outputs
Set Up the Test Environment
Prepare the hardware, software, and network environment for testing. This may involve setting up servers, databases, and testing tools.
Execute Test Cases
Run the test cases and observe the system’s behavior. Record the actual results and compare them with the expected results.
Defect Reporting
If any issues are found, report them to the development team for fixing. Defects should be logged with detailed information, including the steps to reproduce the issue.
Retest
Once defects are fixed, retest the system to ensure the issues have been resolved and that no new issues have been introduced.
Test Completion
Once all the test cases have been executed, and the system is validated, generate a test summary report that includes the results of the testing and any unresolved issues.
Example of a Simple System Test Case
Let’s say you are testing a login functionality on a website. Here’s an example test case:
Test Case ID: TC001
Test Description: Verify that the user can log in with valid credentials.
Test Steps:
Open the login page.
Enter a valid username and password.
Click the “Login” button.
Expected Result: The user should be redirected to the dashboard.
Actual Result: The user is redirected to the dashboard (Assumed Passed).
Best Practices for System Testing
Start Early: Begin system testing early in the software development life cycle (SDLC) to detect defects as soon as possible.
Test in Different Environments: Make sure to test the system in various environments to ensure compatibility.
Automate Repetitive Tests: Use test automation tools to run repetitive tests, especially for regression testing.
Maintain Clear Documentation: Keep detailed logs of test cases, test results, defects, and fixes.
Involve Different Stakeholders: Include various team members such as developers, QA testers, and business analysts to get different perspectives on the system.
Prioritize Critical Areas: Focus on testing critical areas of the system, such as security and performance, before others.
Tools for System Testing
There are many tools available to assist in system testing, depending on the type of testing you need to perform. Here are some common tools:
Selenium: For automating web application testing.
JMeter: For performance and load testing.
Postman: For testing APIs.
OWASP ZAP: For security testing.
TestComplete: For automated functional testing.
LoadRunner: For performance and load testing.
Conclusion
System testing is an important step in ensuring the software functions correctly and meets all requirements. By following the steps and best practices outlined in this tutorial, you can effectively carry out system testing, identify defects, and ensure that the system is ready for deployment.
You can also Visit other tutorials of Embedded Prep
MISRA C MISRA C++: Are you new to embedded systems programming and want to write safe, secure, and reliable C/C++ code? This beginner-friendly tutorial is your ultimate guide to understanding and applying MISRA-C and MISRA-C++ guidelines in real-world embedded projects.
In this MISRA C MISRA C++ Guidelines 2025 edition, we’ll walk you through:
✅ What is MISRA and why it’s important for automotive, aerospace, medical, and other safety-critical industries ✅ Detailed explanation of key MISRA-C and MISRA-C++ rules, including examples and rationale ✅ How to write compliant code step-by-step, avoiding undefined behavior and bugs ✅ Common pitfalls and how to fix violations in your code ✅ Using static analysis tools (like Parasoft, PC-lint, etc.) to check for compliance ✅ Practical tips for integrating MISRA compliance into your development workflow
This tutorial is crafted to help beginners and professionals alike gain confidence in writing MISRA-compliant code—one concept at a time.
Let’s make your embedded software robust, maintainable, and industry-ready in 2025!
MISRA C MISRA C++ :
What is MISRA?
MISRA stands for Motor Industry Software Reliability Association. It is a set of software development guidelines for the C and C++ programming languages, especially designed to:
Improve code reliability, portability, and safety
Avoid undefined behavior and compiler-specific behavior
Ensure code can be used in critical systems, especially in automotive, aerospace, medical, and industrial software
Why Use MISRA-C MISRA-C++?
In embedded and safety-critical systems, even a small bug can lead to huge failures. MISRA helps you write safe, predictable, and standardized code that:
Avoids risky language features
Is easier to analyze and test
Can be certified for safety (like ISO 26262 in automotive)
Difference Between MISRA C MISRA C++
Feature
MISRA-C
MISRA-C++
Language Focus
C (especially C90, C99, C11)
C++ (mainly C++03, some C++11)
Use Case
Widely used in embedded C
Less common, but used in modern automotive software (e.g., ADAS)
Latest Version
MISRA C:2012 (with amendments)
MISRA C++:2008
Structure of MISRA C MISRA C++ Guidelines
Each rule is categorized by:
1. Category
Mandatory – Must always be followed
Required – Should be followed; deviations must be documented
Advisory – Good practice; optional
2. Rule Types
Directive – High-level rule (e.g., All code should be traceable to a requirement)
Functions should have internal linkage if not used outside the file
✅ static void helper()
Rule 11.4
Avoid casting between pointers to different object types
❌ int *x = (int*)ptr;
Rule 17.7
Do not use goto
❌ goto error;
Rule 21.1
Use of standard library functions should be limited
❌ system("rm -rf /")
Common MISRA-C++ Rules (Simplified Examples)
Rule
Description
Example
Rule 0-1-1
Avoid compiler-specific extensions
❌ __attribute__((packed))
Rule 5-0-15
Do not use reinterpret_cast
❌ reinterpret_cast<int*>(ptr)
Rule 6-4-1
Do not use multiple inheritance
❌ class A: public B, public C
Rule 7-1-1
Avoid using new and delete
Prefer static memory or smart pointers
How to Start Using MISRA in Your Project
Read the Guidelines
Official documents are paid but summaries are available online
Use a Static Code Analyzer Tools like:
Parasoft
PC-lint / FlexeLint
Coverity
Cppcheck (partial support)
Write Clean and Portable Code Follow:
No goto
No dangerous casts
No dynamic memory unless necessary
Always initialize variables
Use Compiler Warnings Set high warning levels and treat warnings as errors.
Example MISRA-Compliant C Code
#include <stdint.h>
static int32_t add_numbers(int32_t a, int32_t b) {
int32_t result = a + b; // Always initialized
return result;
}
int main(void) {
int32_t sum = add_numbers(5, 10);
return 0; // No dynamic memory, no undefined behavior
}
Example: Low-level firmware, device drivers, or bare-metal embedded systems.
You’re working with microcontrollers with limited memory and no operating system.
Safety and reliability are critical (automotive ECUs, medical devices, industrial sensors).
You want to avoid risky or undefined behaviors in C (e.g., pointer misuse, buffer overflows).
You need to follow standards like ISO 26262, DO-178C, IEC 61508, etc.
Common Domains: Automotive, medical devices, industrial automation, robotics, defense.
Use MISRA-C++ When:
Your project uses C++ instead of C.
You’re building complex embedded applications using object-oriented design (e.g., control systems, infotainment systems).
You want to leverage C++ features (e.g., classes, inheritance, templates) but still need safety and predictability.
Your team has C++ experience and your toolchain supports it.
You need to comply with C++-specific safety standards (e.g., AUTOSAR Adaptive Platform).
Common Domains: Automotive (infotainment, ADAS), drones, robotics, aerospace control systems.
Still Confused?
Use MISRA-C if you’re writing in pure C, especially for low-level or real-time systems.
Use MISRA-C++ if your embedded project uses modern C++, and you want to combine safety with high-level features.
Summary
Term
Meaning
MISRA
Coding rules for safety-critical software
Mandatory
Must follow
Required
Should follow (document if not)
Static Tool
Tool to check MISRA violations
Beginner-Level Questions
What is MISRA? Why is it important?
What are the goals of MISRA-C / MISRA-C++?
What is the difference between MISRA-C and MISRA-C++?
What do “Mandatory”, “Required”, and “Advisory” rules mean?
What is undefined behavior in C, and how does MISRA help avoid it?
Why does MISRA disallow the use of goto?
Why should dynamic memory (malloc, new) be avoided in embedded systems according to MISRA?
Why does MISRA suggest using static for functions not used outside the file?
Why is type casting between incompatible types discouraged in MISRA?
Can you name a few standard C functions that MISRA recommends avoiding?
Intermediate-Level Questions
Explain the difference between a directive and a rule in MISRA.
How does MISRA ensure portability across compilers and architectures?
What are some limitations or criticisms of MISRA rules?
How do you apply MISRA rules in a real project?
What tools have you used to enforce MISRA compliance?
What is a deviation? How is it handled in MISRA compliance?
Explain Rule 11.4 (Avoid conversion between pointers to different object types).
Why does MISRA-C++ restrict the use of multiple inheritance and virtual functions?
How would you fix a violation of Rule 8.7 (Functions with internal linkage)?
How do you handle third-party code that violates MISRA guidelines?
Advanced-Level Questions
How would you implement a MISRA compliance process in an existing codebase?
What challenges do you face while using static analysis tools for MISRA?
How do MISRA-C and ISO 26262 relate in terms of functional safety?
What are the implications of using reinterpret_cast in C++ for safety-critical systems?
Explain how MISRA helps in enabling formal verification or model-based design.
Can you give an example of a rule violation that caused a bug or issue in production?
How do you justify a deviation with traceability to requirements?
How do you balance performance optimization and MISRA compliance?
What is the difference between MISRA C:2004 and MISRA C:2012?
Have you ever written custom rules in a static analysis tool to supplement MISRA?
FAQ: MISRA-C / MISRA-C++ Guidelines
1. What is MISRA?
MISRA (Motor Industry Software Reliability Association) is a set of coding guidelines for C and C++ designed to help developers write safe, secure, and portable code—especially in safety-critical industries like automotive, aerospace, and medical devices.
2. What is the difference between MISRA-C and MISRA-C++?
MISRA-C applies to the C programming language (mostly used in embedded systems).
MISRA-C++ applies to the C++ language, offering guidance for object-oriented programming in critical systems.
3. Why should I follow MISRA guidelines?
Following MISRA helps:
Prevent undefined behavior
Improve code reliability and maintainability
Ensure safety and compliance with industry standards (e.g., ISO 26262)
4. Is MISRA only for the automotive industry?
No. Although MISRA was started by the automotive industry, it is now widely adopted in aerospace, medical, railway, industrial control, and defense sectors.
5. Do I need special tools to check for MISRA compliance?
Yes, most developers use static analysis tools like:
PC-lint
Parasoft
Coverity
Helix QAC These tools automatically detect violations of MISRA rules in your code.
6. Are all MISRA rules mandatory?
No. MISRA guidelines include:
Mandatory rules (must always be followed)
Required rules (must be followed unless a formal deviation is documented)
Advisory rules (recommended best practices)
7. Can I use dynamic memory (malloc, free) in MISRA-compliant code?
Generally, MISRA discourages or forbids dynamic memory in embedded systems because of potential issues like fragmentation and non-determinism, especially in real-time systems.
8. How do I start learning MISRA guidelines as a beginner?
Start by:
Understanding basic C/C++ syntax and behavior
Reading MISRA rule categories (e.g., syntax, type safety, portability)
Studying real-world code examples
Using static analysis tools to get hands-on experience
9. What’s covered in this tutorial?
This tutorial covers:
Introduction to MISRA-C and MISRA-C++
Deep dive into key rules with code examples
Step-by-step guidance to write compliant code
Static analysis integration
How to document deviations and avoid common mistakes
10. Do I need to buy the official MISRA documents?
While the official MISRA documents provide complete rule sets and rationale, this tutorial offers simplified, beginner-friendly explanations. However, if you’re working professionally, it’s recommended to purchase the official documentation from the MISRA website.
You can also Visit other tutorials of Embedded Prep
Code Coverage Tools : In this comprehensive and beginner-friendly tutorial, we will explore the world of code coverage tools, which play a crucial role in ensuring your software is thoroughly tested and reliable. Whether you’re working on embedded systems, desktop applications, or large-scale software projects, understanding code coverage is essential for improving software quality and identifying untested parts of your codebase.
By the end of this tutorial, you will have a solid understanding of how code coverage tools work and how to integrate them into your own development workflow. Whether you are a student, a developer in testing, or an embedded systems engineer, this guide will empower you to write better-tested and more robust code in 2025 and beyond.
What Is Code Coverage?
Code coverage is a metric used to measure how much of your source code has been executed (or “covered”) during testing. It helps answer questions like:
Have all functions been tested?
Have all branches or conditions been exercised?
Are there any unused lines of code?
In simple terms, code coverage tools help ensure your tests are doing their job.
Why Code Coverage Matters
✅ Identifies untested parts of code
🚨 Helps find dead code or redundant logic
🔍 Improves software reliability
📊 Provides quality insights for QA, DevOps, and Developers
💬 Useful in code reviews and CI/CD pipelines
Types of Code Coverage Metrics
Type
Description
Example
Line Coverage
% of lines executed
90 out of 100 lines = 90%
Function Coverage
% of functions called
8 of 10 functions = 80%
Branch Coverage
% of if/else branches executed
Both if and else parts
Condition Coverage
% of boolean sub-expressions tested
if (A && B) tests A and B
Path Coverage
% of possible execution paths tested
All loops + conditions
Popular Code Coverage Tools
Tool
Language
Platform
Usage
gcov
C/C++
Linux
Built-in with GCC
lcov
C/C++
Linux
Visual frontend for gcov
gcovr
C/C++
Cross-platform
Outputs XML/HTML
JaCoCo
Java
Cross-platform
Java code coverage
Coverage.py
Python
Cross-platform
Simple and powerful
Istanbul
JavaScript
Node.js
For JS/TS projects
Tutorial: Using gcov and lcov (For C/C++ Beginners)
This tool summarizes all .gcov into HTML – very handy!
Summary
Code coverage tools help validate testing effectiveness.
For C/C++, gcov, lcov, and gcovr are most used.
Compile with coverage flags, execute the binary, then generate reports.
Visual tools help QA, CI, and reviews.
Code coverage != code quality but is a crucial metric.
We’ll:
Write a simple C program.
Compile it with code coverage flags.
Run it to generate coverage data.
Use gcov to view the coverage.
Optionally, use lcov + genhtml to generate an HTML report.
Step-by-Step Code Coverage Example with Code
Step 1: Write the C Program (math_utils.c)
// math_utils.c
#include <stdio.h>
int add(int a, int b) {
return a + b;
}
int subtract(int a, int b) {
return a - b;
}
int multiply(int a, int b) {
return a * b;
}
int divide(int a, int b) {
if (b == 0) {
printf("Division by zero error!\n");
return 0;
}
return a / b;
}
int main() {
printf("Add: %d\n", add(5, 3));
printf("Subtract: %d\n", subtract(5, 3));
// multiply and divide not called
return 0;
}
This creates extra files like math_utils.gcno (for structure data).
Step 3: Run the Program
./math_utils
Output:
Add: 8
Subtract: 2
This execution will generate math_utils.gcda (runtime data file showing which lines ran).
Step 4: Run gcov to See Coverage
gcov math_utils.c
You’ll see something like:
File 'math_utils.c'
Lines executed:60.00% of 15
Creating 'math_utils.c.gcov'
Then open the file math_utils.c.gcov:
-: 1: // math_utils.c
-: 2: #include <stdio.h>
#####: 3:
1: 4: int add(int a, int b) {
1: 5: return a + b;
-: 6: }
1: 7:
1: 8: int subtract(int a, int b) {
1: 9: return a - b;
-: 10: }
#####: 11: int multiply(int a, int b) {
#####: 12: return a * b;
-: 13: }
#####: 14: int divide(int a, int b) {
#####: 15: if (b == 0) {
#####: 16: printf("Division by zero error!\n");
#####: 17: return 0;
#####: 18: }
#####: 19: return a / b;
-: 20: }
1: 21:
1: 22: int main() {
1: 23: printf("Add: %d\n", add(5, 3));
1: 24: printf("Subtract: %d\n", subtract(5, 3));
-: 25: // multiply and divide not called
1: 26: return 0;
-: 27: }
What You Learn From This
Lines marked #####: <line number> are never executed.
Functions not tested = 0% coverage.
You only called add() and subtract() in main() – so only those got executed.
You’ll see a colorful, user-friendly HTML page showing function/line/branch coverage.
Summary
✅ Code coverage tools like gcov and lcov help track which parts of your code were tested. ✅ Use flags -fprofile-arcs -ftest-coverage during compilation. ✅ gcov gives line-by-line coverage in plain text. ✅ lcov + genhtml gives interactive HTML reports. ✅ Helps you spot untested functions (like multiply() and divide() above).
You can also Visit other tutorials of Embedded Prep
Welcome to the Master Beginner-Friendly Guide to the Embedded Boot Process (2025 Edition)! In this tutorial, you’ll gain a clear and practical understanding of how embedded systems start up — from the moment power is applied to the system until the operating system or application is fully running.
What You Will Learn:
What is the Boot Process? Understand what happens behind the scenes when an embedded device powers on.
Stages of the Boot Process:
Power-On Reset (POR)
Boot ROM / Initial Bootloader
Secondary Bootloader (SPL / U-Boot)
Kernel Loading
Root Filesystem Mounting
User Application Launch
Key Components Involved: Learn about bootloaders, memory maps, non-volatile storage (NAND, NOR, eMMC), and how firmware interacts with hardware.
Bare-metal vs. OS-based Booting: Discover the difference in boot flow when using no OS, RTOS, or full-fledged OS like Linux or QNX.
Practical Example: Walk through a real-world boot sequence on popular boards like STM32, BeagleBone Black, or Raspberry Pi.
Debugging Boot Issues: Learn how to use serial consoles, boot logs, and debugging tools to trace boot-time failures.
Tips for Faster and Reliable Booting Optimize your embedded system’s startup time and stability.
Have you ever wondered what happens when you turn on your computer or a device like a mobile phone or embedded board (e.g., Raspberry Pi, Arduino, etc.)?
Let’s break it down step by step, using simple words!
1. Power ON
When you press the power button:
Electricity flows to the motherboard and components.
This is just like waking up your device from sleep.
2. CPU Starts (but knows nothing!)
The CPU (brain of the system) starts running, but it has no idea what to do.
So, it looks for instructions in a special memory called ROM (Read-Only Memory).
3. BIOS / Bootloader (First Instructions)
The CPU finds a tiny program in ROM, like a mini-guidebook. This is:
BIOS (for PCs) or
Bootloader (in embedded systems or phones)
This program:
Checks if important parts like RAM, keyboard, screen, etc., are working.
Then it looks for the main software (Operating System) to run.
4. Loading the Operating System (OS)
Once the check is done:
It loads the OS (like Windows, Linux, Android, or RTOS) from storage (HDD/SSD/Flash) to RAM.
RAM is like a fast-access workspace where the OS can run quickly.
5. OS Takes Over
Now the OS is running, and:
It manages the hardware.
It starts services and programs.
It shows you the login screen or desktop.
Congratulations! 🎉 Your device is now ready to use!
Quick Summary (Like a Flowchart):
1. Power ON 🔌
2. CPU starts 🧠
3. Bootloader/BIOS runs 📦
4. OS is loaded 💿
5. OS takes control and system is ready 🖥️
Real Life Example (Simple Analogy):
Think of your device like a car:
Battery ON → Supplies power
Ignition Key Turned → CPU wakes up
Dashboard Checks → Bootloader checks parts
Engine Starts → OS is loaded
You Can Drive → System ready for use
U-Boot Basics
What is U-Boot?
U-Boot (short for Universal Boot Loader) is an open-source bootloader used in embedded systems. It helps your device start up, initialize hardware, and load the operating system (like Linux, Android, or RTOS).
Why Do We Need U-Boot?
When you power on an embedded board (like a BeagleBone, STM32, or Raspberry Pi):
1. First Stage Bootloader (SPL – Secondary Program Loader)
Very small size, loaded from ROM or flash.
Initializes basic things like DRAM (RAM).
Loads the full U-Boot image from storage into RAM.
2. Second Stage Bootloader (Full U-Boot)
Runs in RAM.
Has full features: CLI, device drivers, environment variables, loading kernel, etc.
U-Boot in Action – Boot Flow
Let’s say you power on your embedded board:
Power ON
↓
ROM Code (fixed in CPU)
↓
SPL (from SD card, flash)
↓
U-Boot (full version loaded into RAM)
↓
Kernel (Linux, RTOS, etc.)
↓
Root Filesystem
↓
Your Application
Common U-Boot Commands
You interact with U-Boot via a command-line interface (serial terminal like PuTTY, Minicom, TeraTerm).
Here are some commonly used U-Boot commands:
Command
Description
help
List all commands
printenv
Show environment variables
setenv var value
Set environment variable
saveenv
Save variables to flash
boot
Boot the OS
load
Load file into memory
mmc, fatload, ext4load
Load files from SD card (FAT or EXT4)
bootm
Boot a Linux kernel image (uImage)
bootz
Boot a zImage
booti
Boot an Image format (used for ARM64)
run
Run a command script or bootcmd
U-Boot Environment Variables
These are key-value pairs that control how the board boots.
git clone https://source.denx.de/u-boot/u-boot.git
cd u-boot
Step 2: Select Board
make <board_defconfig> # e.g., make am335x_evm_defconfig
Step 3: Build U-Boot
make CROSS_COMPILE=arm-linux-gnueabihf- # or your toolchain prefix
Output Files
u-boot.img – U-Boot image
MLO – SPL (for some boards like BeagleBone)
Flashing U-Boot to Board
SD Card: Place MLO and u-boot.img in boot partition.
Flash Memory: Use tools like dd, flashcp, or manufacturer utilities.
Tips for Beginners
Always backup your current U-Boot before changing it.
Use serial console to access U-Boot.
Keep a bootable SD card as recovery in case of a bad flash.
Learn U-Boot environment—it’s key to customization.
Customizing U-Boot for Embedded Systems
Customizing U-Boot means modifying its behavior to suit your specific board, hardware, or use case — like setting boot arguments, adding splash screens, or enabling new peripherals.
Let’s walk through it step by step 👇
1. Prerequisites
Before customizing, make sure you have:
✅ A Linux PC or VM ✅ A toolchain (like arm-linux-gnueabihf-gcc) ✅ U-Boot source code ✅ Board information (CPU, RAM, Flash type) ✅ Serial communication tool (like Minicom or PuTTY)
2. Get the U-Boot Source Code
git clone https://source.denx.de/u-boot/u-boot.git
cd u-boot
3. Choose the Right Board Configuration
U-Boot uses defconfig files for board settings.
To find yours:
ls configs/
Pick your board (example: BeagleBone Black)
make am335x_evm_defconfig
For custom boards, copy a similar defconfig and modify it.
4. Build U-Boot
export CROSS_COMPILE=arm-linux-gnueabihf-
make -j$(nproc)
mkimage -A arm -T script -C none -n "Boot Script" -d boot.cmd boot.scr
Place boot.scr on SD card — U-Boot will run it automatically.
9. Tips for Custom Boards
Use similar board’s config as starting point.
Add support for your DRAM, clock, storage in board.c and dts.
Customize dts (Device Tree Source) file for Linux as well.
Summary
What You Did
Description
Got U-Boot source
git clone
Chose board config
make defconfig
Customized features
Edited header files, bootcmd
Enabled features
Splash screen, drivers
Rebuilt & flashed
make, dd
Tested via serial
Used setenv, boot
(Optional) Used script
Boot automation with boot.scr
Bootloader Initialization in Embedded Systems
If you’ve ever wondered how your embedded device starts running code, the answer is: it all begins with the bootloader.
Let’s break down what a bootloader is, how it works, and how it initializes your system — step by step.
What Is a Bootloader?
A bootloader is the first program that runs when your embedded system powers up or resets. It prepares your hardware and loads the main firmware (like Linux or RTOS).
Think of it like:
“A mini operating system that wakes up your device, checks everything, and hands control to the main software.”
Why Bootloader Initialization Matters?
Before your firmware (or OS) can run, the hardware needs to be set up properly:
Clock signals must be configured ✅
Memory (RAM, Flash) should be initialized ✅
Peripherals like UART, SPI, etc. must be ready ✅
Bootloader Initialization Step-by-Step
Here’s what typically happens:
1. Reset or Power-On
The microcontroller or processor powers up.
The Program Counter (PC) is set to a fixed boot address.
This points to the bootloader’s start location (usually in Flash memory).
2. Execution Begins: Start.S or crt0.S
The CPU starts running assembly code.
This code does:
Disabling interrupts
Setting up the stack pointer
Copying data from Flash to RAM
Clearing the .bss section (zero-initialized variables)
This is known as the low-level initialization stage.
3. Hardware Initialization (Board-Level)
Now, the bootloader code written in C takes over (often in board_init() or main() function).
It does:
Configures CPU clock frequency
Initializes UART (for printing messages)
Initializes SDRAM (if external)
Sets up power management (PMIC)
Prepares GPIOs, I2C, SPI, etc.
This code is often board-specific and may live in board.c or init.c in U-Boot.
4. Detect and Load Firmware
The bootloader then:
Detects the storage device (eMMC, SD card, SPI flash, etc.)
Loads the main firmware (like zImage, uImage, or RTOS binary) into RAM
Sets up boot arguments (bootargs)
Jumps to the entry point of the firmware
Think of this as: “Here’s your OS. Time to run it!”
5. Hand-Off to OS
Finally, the bootloader does a jump to the firmware:
In custom bootloaders: You write it from scratch or using templates.
In U-Boot: It’s split into files like start.S, board.c, init.c, etc.
In microcontrollers: It’s often written in startup.s, main.c, and linked via linker script.
Tools Needed
Tool
Purpose
Cross Compiler (like arm-none-eabi-gcc)
To build bootloader
Serial Console (Minicom, PuTTY)
To see logs via UART
Flashing Tool (dd, OpenOCD)
To write bootloader to flash
Summary
Bootloader Stage
Action
Power-On
CPU starts from fixed address
Low-level Init
Stack, memory, .bss, vectors
Board Init
Clock, UART, RAM, peripherals
Load Firmware
Read from Flash or SD
Jump to OS
Handoff control
Final Words
Bootloader initialization is the foundation of system bring-up. If something goes wrong here, nothing else works.
Start simple, log every step, and understand what your hardware needs to “wake up.”
Here’s a Beginner-Friendly Guide to Secure Boot — explained step-by-step for someone with zero background in security or bootloaders.
Beginner-Friendly Tutorial: What is Secure Boot?
Why This Matters?
Imagine your embedded device is like a home. Would you want just anyone to unlock your door and change how it works? No! That’s where Secure Boot comes in.
Secure Boot makes sure that only trusted software can run when your embedded system starts. It protects against malware, tampering, and unauthorized code.
What is Secure Boot?
Secure Boot = A locked gate that only opens for verified, trusted software.
It’s a security feature in bootloaders (like U-Boot) and processors. Before booting the main firmware or OS, Secure Boot checks the signature of the software image. If it’s valid (not tampered), it boots. Otherwise, it stops.
Simple Analogy
Think of it like scanning a QR code to enter a room. If the code is valid and signed, you’re in. If someone changes the QR code, the scanner refuses access.
How Does Secure Boot Work? (Step-by-Step)
Step 1: Key Generation
A private/public key pair is created using cryptography (like RSA or ECC).
Private Key → Secret (kept by the manufacturer)
Public Key → Stored in the device (in hardware or ROM)
Step 2: Signing the Firmware
The firmware (like a Linux image or RTOS) is hashed and then digitally signed with the private key.
This creates a signature file attached to the firmware.
Step 3: Burning the Public Key
The public key is stored in a trusted area of the device (like One-Time Programmable (OTP) memory or eFuse).
This makes it impossible to change later (hardware enforced).
Step 4: Secure Boot Process
When the system powers up:
Boot ROM (or Primary Bootloader) is executed from secure memory.
It reads the firmware (e.g., u-boot.img, zImage).
It verifies the signature using the stored public key.
If valid → The boot continues.
If invalid → Boot is aborted (or recovery mode is triggered).
U-Boot will now verify the signature before booting!
What Happens If Tampered?
If someone modifies the kernel or DTB:
U-Boot’s signature verification will fail
The boot will be aborted
You’ll see a message like:
Error: verification failed for 'kernel@1'
Bonus: Secure Boot Chain
Stage
Verified?
Boot ROM (SoC)
Yes – hardwired
SPL (Secondary Bootloader)
Yes – optional signature
U-Boot Proper
Yes
Linux Kernel (FIT image)
Yes
Root Filesystem
No (unless additional mechanisms used like dm-verity)
Want to try on STM32 or NXP i.MX?
Each vendor has slight variations:
STM32 uses OEM keys, STM32CubeProgrammer, and Secure Boot Services
NXP i.MX uses AHAB, CST tool, and fuse-based key provisioning
I can guide you through those too if needed.
Bootloader for Flash Memory
When working with embedded systems, one crucial component that ensures your system boots correctly is the Bootloader. The Bootloader for Flash Memory is responsible for loading the operating system (or kernel) from flash storage to RAM when the system powers up.
What is a Bootloader?
A Bootloader is small software that runs when a system is powered on. It’s responsible for initializing the hardware and loading the main operating system (OS) or kernel.
When the system starts, it first checks if the bootloader is present in flash memory. If so, it loads and runs the bootloader. The bootloader then locates the kernel in the flash memory and transfers control to it.
Flash Memory Overview
Flash memory is a type of non-volatile storage, which means it retains data even after power is lost. It’s commonly used to store the bootloader, operating system, and sometimes user data.
Two Key Types of Flash Memory:
NOR Flash – Faster read speeds, slower writes, often used for storing the bootloader and firmware.
NAND Flash – Slower reads, faster writes, typically used for storing large amounts of data (like operating systems).
How Does the Bootloader Work with Flash Memory?
When the system powers up, the processor or microcontroller will follow this sequence:
1. Power-Up / Reset:
The CPU starts in a known state from ROM (Read-Only Memory).
2. Boot ROM:
The Boot ROM (part of the processor) is the very first code that runs. It may contain a simple routine to check if a valid bootloader is present in the flash memory.
3. Loading Bootloader:
The Boot ROM will read the bootloader from flash memory (e.g., NOR Flash) and load it into RAM.
4. Bootloader Execution:
The Bootloader then executes, initializing the system and setting up hardware like memory, peripherals, and communication interfaces.
5. Loading the Operating System:
Once the hardware is initialized, the bootloader locates the kernel (or OS image) stored in the flash memory, loads it into RAM, and then transfers control to the kernel.
Flash Memory as Boot Storage
In most embedded systems, the bootloader resides in Flash memory. Flash memory has both read and write capabilities, allowing it to store the bootloader and kernel in a way that survives resets or power cycles.
How to Set Up a Bootloader for Flash Memory
Here’s a simple overview of how you can create and set up a bootloader for your system that uses flash memory:
1. Choose the Flash Memory Type
Decide whether your system uses NOR or NAND flash.
NOR Flash is often used for bootloaders because it allows faster reading, making it ideal for the first step in the boot process.
2. Configure the Bootloader for Flash Memory
U-Boot is one of the most commonly used bootloaders for embedded systems. You need to configure it to work with your flash memory type (NOR/NAND).
For example, U-Boot allows you to configure it with:
CONFIG_SYS_FLASH_BASE for NOR flash
CONFIG_SYS_NAND_BASE for NAND flash
These configurations tell the bootloader where to read from in the flash memory.
3. Prepare Flash Memory for Bootloader
Flash Programming: You’ll need to program the flash memory with your bootloader and OS image.
Flashing tools like JTAG, USB-to-Serial, or a flasher can help in writing to flash memory.
4. Create the Bootloader Image
Once U-Boot (or any other bootloader) is configured, you need to create an image that can be written to flash.
Example U-Boot image creation: make CROSS_COMPILE=arm-linux-gnueabihf- u-boot.img
5. Flash the Bootloader
After compiling the bootloader image (u-boot.img), you can use tools to write it into the flash memory.
After writing the bootloader into flash memory, power on the system and watch the boot process to verify if the system boots correctly from flash.
Simple Boot Process Using Flash Memory:
Here’s a very simplified sequence of the boot process when using flash memory:
Power-On → Boot ROM → Load Bootloader (from Flash) → Bootloader Executes → Load Kernel (from Flash) → Boot OS
In Detail:
Power-On: System powers up, and the CPU starts from ROM.
Boot ROM: The Boot ROM checks for valid bootloader code in the flash memory.
Bootloader Loads: The bootloader (e.g., U-Boot) is loaded into RAM.
Bootloader Initialization: The bootloader configures hardware and prepares the system for loading the OS.
Load Kernel: The bootloader reads the kernel image from flash and loads it into RAM.
OS Control: The bootloader transfers control to the kernel, and the operating system begins running.
Flash Memory and Security:
To ensure that the boot process is secure and unmodified, you can implement Secure Boot. This ensures that only trusted bootloader and kernel images are loaded from flash memory. It typically involves digital signatures to verify the integrity of the bootloader and OS image.
Real Example with U-Boot for Flash Memory:
Let’s walk through a basic process of using U-Boot to load the OS from flash memory:
1. Prepare U-Boot Configuration
In your u-boot/configs directory, configure the board for flash memory:
make am335x_evm_defconfig
Modify the U-Boot configuration for flash memory access (for example, for NAND):
make menuconfig
# Enable NAND and configure memory
2. Build U-Boot
Now, build the U-Boot image for your system:
make CROSS_COMPILE=arm-linux-gnueabihf- u-boot.bin
3. Flash U-Boot to NAND/NOR
Use a flashing tool to program U-Boot to the flash memory:
sudo dd if=u-boot.bin of=/dev/nand1 bs=512 seek=1
4. Verify Boot Process
Once U-Boot is installed, power on the device. It should automatically load the OS (or kernel) from flash memory.
Frequently Asked Questions (FAQs)
Q: What is the difference between U-Boot and BIOS? A: BIOS is for PCs; U-Boot is for embedded systems. Both initialize hardware and boot the OS.
Q: Can U-Boot run scripts? A: Yes, using environment variables and run command.
Q: Is U-Boot customizable? A: Yes! It’s open source, so you can add/remove features and drivers.
Key Takeaways:
Bootloaders load your OS/kernel from flash memory.
Flash Memory is non-volatile, making it perfect for boot storage.
U-Boot is commonly used as a bootloader for embedded systems.
Secure Boot adds authentication to make sure only trusted code is run.
You can also Visit other tutorials of Embedded Prep
SDLC Software Development Life Cycle : The Software Development Life Cycle (SDLC) is a step-by-step process used to build software efficiently. Think of it like a recipe 📜 — it guides you from the idea stage to a fully cooked (working!) application.
SDLC Software Development Life Cycle
1. Requirements Analysis
Goal: Understand what the software needs to do.
In this phase, developers talk to clients or users to find out:
What problem the software should solve
What features are needed
Who will use it, and how
Deliverable: A document that lists clear software requirements.
Tip: Imagine you’re building an app like a food delivery service. This phase figures out: Do users need real-time tracking? How should payment work?
2. Design Phase
Goal: Plan how the software will work internally and externally.
📊 Based on the requirements, software architects and developers:
Design the system structure (modules, databases, UI layout)
Choose the technologies (programming languages, tools)
🖼️ It’s like creating blueprints before constructing a building.
Work is divided into small cycles (sprints), and each cycle delivers a usable part of the product.
Plan ➡ Design ➡ Develop ➡ Test ➡ Review ➡ Repeat (for each sprint)
Pros:
Flexible and adaptive to change
Continuous feedback and improvement
Faster delivery of features
Cons:
Needs close communication with clients
Requires experienced teams to manage sprints well
Summary Table SDLC Software Development Life Cycle
Feature
Waterfall Model
Agile Model
Approach
Linear (one-time flow)
Iterative (repeats)
Flexibility
Low
High
Customer Involvement
At the beginning only
Ongoing, frequent
Best For
Simple, fixed-scope projects
Evolving, complex projects
Delivery Style
One big release
Small, regular releases
Conclusion SDLC Software Development Life Cycle
The SDLC helps developers stay organized and efficient when building software. Whether you’re working on a simple school project or a large enterprise system, understanding SDLC is essential.
Start with requirements
Move through design and implementation
Carefully test and maintain
Choose the right model: Agile for flexibility, Waterfall for simplicity
The Agile Model is a software development methodology that emphasizes iterative development, customer collaboration, responding to change, and frequent delivery of working software. Unlike traditional waterfall models, Agile does not follow a strict sequence of phases like
it divides the project into small iterations or sprints where all activities (like design, coding, testing) happen in parallel.
Overview of the Agile Model
Agile is adaptive, not predictive. It follows the Agile Manifesto, which emphasizes:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile isn’t a single process but a set of principles and values. However, it is implemented using frameworks like Scrum, Kanban, Extreme Programming (XP), etc.
Core Phases / Processes of the Agile Model
Although Agile is iterative and phases often overlap, it still follows a cycle in each iteration or sprint.
1. Concept / Requirement Gathering
Goal: Understand what the customer wants.
Process:
Stakeholders describe high-level features (called epics or user stories).
Product owner adds these to the product backlog.
Tools: User Story format (As a [user], I want [feature] so that [benefit]), JIRA, Trello.
2. Planning (Sprint Planning)
Goal: Plan what can be delivered in the upcoming sprint (usually 1-4 weeks).
Process:
Product Owner prioritizes user stories.
Team selects stories they can commit to during the sprint.
Tasks are broken down and estimated (e.g., in story points or hours).
3. Design
Goal: Quickly plan the architecture/design of selected features.
Process:
Collaborative design with minimal upfront effort.
Use diagrams (e.g., UML), whiteboards, or design tools.
Note: Agile supports evolutionary design—it evolves as development proceeds.
4. Development / Implementation
Goal: Write working code that meets the sprint goal.
Process:
Developers start coding as per stories/tasks.
Code is regularly pushed, integrated (often daily), and unit-tested.
Continuous Integration (CI) pipelines are often used.
5. Testing
Goal: Ensure the functionality meets the acceptance criteria.
Process:
Testers write test cases for each user story.
Conduct functional testing, regression testing, and sometimes automated testing.
Defects found are resolved within the same sprint.
6. Deployment / Release
Goal: Deliver working software to users or staging environments.
Process:
Software can be released at the end of every sprint (if shippable).
Use DevOps practices like CI/CD for faster releases.
7. Review (Sprint Review)
Goal: Demonstrate completed features to stakeholders.
Process:
Team presents what was completed.
Stakeholders provide feedback.
Feedback is noted and can become new user stories.
8. Retrospective
Goal: Improve the process for future sprints.
Process:
Team discusses what went well, what didn’t, and what can be improved.
Action items are recorded and applied in the next sprint.
Agile Iteration Cycle Summary
User Story → Sprint Planning → Design → Development → Testing → Sprint Review → Retrospective → Next Sprint
Each sprint is time-boxed and results in a potentially shippable product increment.
Key Agile Terms SDLC Software Development Life Cycle
Term
Description
User Story
A feature described from the user’s perspective.
Sprint
A fixed-duration iteration (usually 1–4 weeks).
Backlog
A prioritized list of user stories.
Scrum Master
Facilitates Scrum practices and removes blockers.
Product Owner
Owns the product vision and backlog.
Daily Standup
A 15-minute meeting to sync up.
Burndown Chart
Shows remaining work in a sprint.
Benefits of Agile
Fast delivery of features
Flexibility to changes
Continuous user feedback
High product quality
Encourages teamwork and transparency
When Agile May Not Be Suitable
Projects with very fixed scope and budget
Safety-critical or heavily regulated systems (unless Agile is tailored carefully)
Teams unfamiliar with Agile principles
Project Management & Collaboration
Jira – Widely used for Scrum/Kanban boards, user stories, sprints, and burndown charts.
Trello – Visual task management using boards and cards (popular for small teams).
Asana – Task tracking with project timelines and collaboration.
ClickUp – Combines tasks, docs, and goals in one platform.
VersionOne – Agile project management tool supporting SAFe and Scrum.
Azure DevOps (formerly VSTS) – Integrated with Microsoft tools for Agile planning and CI/CD.
Source Control & Code Management
Git – Distributed version control system.
GitHub / GitLab / Bitbucket – Platforms for Git repositories with built-in issue tracking and CI/CD.
CI/CD & Build Automation
Jenkins – Automates builds and deployments.
CircleCI / Travis CI / GitLab CI – Integrates with Git to run automated pipelines.
TeamCity – JetBrains tool for continuous integration and delivery.
Testing Tools
Selenium – Web application automation testing.
JUnit / NUnit / TestNG – Unit testing frameworks.
Postman – API testing.
Cucumber – BDD tool for writing test cases in plain English.
QTest – Test case management.
Documentation & Knowledge Sharing
Confluence – Wiki-style documentation often paired with Jira.
Notion – All-in-one workspace for docs, tasks, and wikis.
Google Docs/Sheets – Lightweight collaboration tools for real-time editing.
Monitoring & Feedback
Burndown/Burnup Charts – Usually generated within tools like Jira.
Retrospective Tools – EasyRetro, FunRetro for sprint reviews.
Slack / Microsoft Teams – Team communication and real-time updates.
Let’s include IBM tools that are widely used in Agile and systems engineering environments, especially in regulated industries like automotive, aerospace, and healthcare.
🏢 IBM Tools in Agile Methodology
IBM Jazz Platform
A collaborative lifecycle management (CLM) platform designed for Agile and DevOps:
IBM Engineering Workflow Management (EWM)
Formerly: Rational Team Concert (RTC)
Used for: Agile planning, work item tracking, SCM, and builds.
Features: Sprint planning, Kanban boards, task tracking, and integrations.
IBM Engineering Requirements Management DOORS Next (DNG)
Formerly: DOORS Next Generation
Used for: Requirements elicitation, management, and traceability.
Features: Collaboration on requirements in Agile teams, linking to user stories, test cases, and code.
IBM Engineering Requirements Management DOORS (Classic DOORS)
Used for: Hierarchical, structured requirements in complex systems.
Features: Traceability, baselining, and change control.
Still widely used in large legacy and safety-critical projects.
IBM Engineering Test Management (ETM)
Formerly: Rational Quality Manager (RQM)
Used for: Test planning, execution, and linking to requirements and development tasks.
IBM Engineering Lifecycle Optimization – Engineering Insights (ENI)
Used for: Visualizing relationships between artifacts like requirements, code, and test cases.
These IBM tools are tightly integrated and support Agile at scale, traceability, compliance, and complex product development lifecycles, especially when following frameworks like SAFe or ASPICE.
FAQ: Software Development Life Cycle (SDLC)
1. What is SDLC? Answer: SDLC (Software Development Life Cycle) is a structured process used by software developers and project teams to design, develop, test, deploy, and maintain software applications. It ensures the quality and correctness of software.
2. What are the main phases of SDLC? Answer: The typical SDLC phases are:
Requirement Gathering & Analysis
System Design
Implementation (Coding)
Testing
Deployment
Maintenance
3. Why is SDLC important? Answer: SDLC provides a clear framework that helps ensure systematic development, minimizes risks, ensures quality, and delivers projects on time and within budget.
4. What are some common SDLC models? Answer: Common SDLC models include:
Waterfall Model
Agile Model
V-Model (Validation and Verification Model)
Spiral Model
Iterative Model
Big Bang Model
5. What is the difference between Waterfall and Agile? Answer:
Waterfall is linear and sequential; each phase must be completed before the next.
Agile is iterative and flexible; development is done in small sprints with regular feedback and continuous improvement.
6. What happens in the Requirement Gathering phase? Answer: In this phase, business analysts and stakeholders gather and document the functional and non-functional requirements of the system.
7. What does the Design phase include? Answer: The design phase includes system architecture, data models, user interfaces, and technical specifications. It serves as a blueprint for development.
8. What is the role of testing in SDLC? Answer: Testing ensures that the software meets requirements and is free from defects. It includes unit testing, integration testing, system testing, and user acceptance testing (UAT).
9. How is maintenance handled in SDLC? Answer: After deployment, software needs regular updates, bug fixes, security patches, and performance improvements. This is managed in the maintenance phase.
10. What tools are commonly used in SDLC? Answer:
Requirement Management: JIRA, Confluence
Design: UML tools, Draw.io
Development: IDEs like VS Code, IntelliJ
Testing: Selenium, JUnit, TestNG
Version Control: Git, GitHub
CI/CD: Jenkins, GitLab CI
11. Who are the key participants in SDLC? Answer: Stakeholders include Business Analysts, Project Managers, Developers, Testers, DevOps Engineers, and Customers.
12. Can SDLC be used in embedded software development? Answer: Yes, SDLC applies to embedded systems as well, with adaptations for hardware constraints, real-time requirements, and integration with physical devices.
You can also Visit other tutorials of Embedded Prep
Git Basics : In this blog post, we will dive deep into the core concepts of Git, one of the most widely used version control systems in modern software development. Whether you’re a beginner or looking to brush up on Git, this guide will help you understand how to efficiently manage and track your codebase.
We’ll start by covering the Git Basics such as cloning repositories, committing changes, pushing and pulling updates, and how these foundational commands are used in everyday development. After that, we’ll explore the power of Branching and Merging, which enables parallel development on separate features or fixes without disrupting the main codebase.
Next, we will dive into Git Workflow and examine popular strategies like Feature Branch Workflow and Git Flow, and explore the commands necessary to follow these workflows effectively. We’ll also tackle Conflict Resolution — a common challenge when collaborating with others — and provide best practices for resolving merge conflicts.
Furthermore, we will compare Git Rebase vs Merge, and understand their differences, use cases, and impact on project history. Finally, we will wrap up with Git Tags and Releases, showing how to mark specific points in your project’s history, such as version releases, and how to manage them with tags.
By the end of this post, you’ll have a solid understanding of Git’s key features and commands, enabling you to collaborate smoothly in any software development project.
1. Git Basics Overview:
Git is a distributed version control system that helps developers manage and track changes to their codebase over time. It allows multiple users to collaborate on the same project without overwriting each other’s changes. Below are the basic Git commands that are commonly used in any development project.
Clone: git clone is used to create a local copy of a remote repository. This command pulls down all the files, commit history, and branches from the remote repository to your local machine. git clone <repository_url> Example: git clone https://github.com/user/project.git
Commit: A commit represents a snapshot of your changes. After modifying files in your working directory, you need to add them to staging and commit them to the local repository.
Stage files: git add <file> adds specific files to the staging area. To add all changed files, use git add .. git add .
Commit changes: Once your files are staged, you use the git commit command to save your changes to the local repository. git commit -m "Commit message describing changes"
Push: The git push command is used to upload local repository content to a remote repository. It is typically used after committing changes locally to push them to a shared remote repository. git push origin <branch_name> Example: git push origin main
Pull: git pull is used to fetch and integrate changes from the remote repository into your local branch. This command combines git fetch and git merge, ensuring you have the latest changes from the remote branch. git pull origin <branch_name> Example: git pull origin main
Branching & Merging
2. Branching:
Branching allows you to create separate environments to work on different features or fixes without affecting the main codebase. Each branch can be developed independently and then merged back into the main branch.
Create a branch: You can create a new branch with the git branch command. git branch <branch_name> Example: git branch feature/new-feature
Switch to a branch: To start working on a branch, use git checkout to switch to it. git checkout <branch_name> Example: git checkout feature/new-feature Alternatively, you can combine both creating and switching with: git checkout -b <branch_name> Example: git checkout -b feature/new-feature
3. Merging:
Merging is the process of bringing together changes from different branches. Typically, changes from a feature branch are merged back into the main branch.
Merge a branch: First, ensure you’re on the branch that you want to merge into (typically main or master), then use the git merge command. git merge <branch_name> Example: git merge feature/new-feature
Git Workflow (Feature Branch, Git Flow) and All Commands
4. Git Workflow:
Git workflow refers to how developers manage their branches and commits within a repository. Two popular workflows are the Feature Branch workflow and Git Flow workflow.
Feature Branch Workflow: In this workflow, each new feature or bug fix is developed in a separate branch. When the feature is complete, it’s merged into the main branch. Steps:
Create a feature branch: git checkout -b feature/awesome-feature
Open a pull request (PR) and merge into the main branch.
Git Flow: Git Flow is a more structured branching model, often used in larger projects. It divides work into different branches for features, releases, and hotfixes.
Main branches:
main (or master): Production-ready code.
develop: Ongoing development code, where new features are integrated.
Supporting branches:
Feature branches: Used for new features.
Release branches: Prepare for production releases.
Hotfix branches: Used to fix urgent issues in production.
Git Flow commands: Install git-flow: brew install git-flow Initialize git flow in a repository: git flow init Start a feature: git flow feature start <feature_name> Finish a feature: git flow feature finish <feature_name> Start a release: git flow release start <release_version> Finish a release: git flow release finish <release_version> Start a hotfix: git flow hotfix start <hotfix_version> Finish a hotfix: git flow hotfix finish <hotfix_version>
💛 Support Embedded Prep
If you find our tutorials helpful and want to support our mission of sharing high-quality embedded system knowledge, you can contribute by buying us a coffee.
Every small contribution helps us keep creating valuable content for learners like you. ☕
Thank you for your support — it truly keeps Embedded Prep growing. 💻✨
Conflict Resolution
5. Conflict Resolution:
When merging branches, you might encounter conflicts if two branches modify the same part of a file. Git cannot automatically decide which change should be kept, so it marks the conflict in the file.
Resolve Conflicts: When a conflict occurs, Git will mark the file with conflict markers. Open the conflicted file, look for the markers (e.g., <<<<<<<, =======, >>>>>>>), and manually resolve the conflict by selecting or merging the appropriate changes.
After resolving conflicts: Once you’ve resolved the conflict, stage the file and commit the merge. git add <conflicted_file> git commit
Git Rebase vs Merge
6. Git Rebase vs Merge:
Merge: When you use git merge, you combine the histories of two branches into a single branch. A merge commit is created to maintain the history of both branches.
Pros: Maintains a full history of commits, which can be useful for tracking changes.
Cons: The history can become messy with multiple merge commits.
git merge <branch_name>
Rebase: git rebase moves or “replays” your commits from one branch onto another. It results in a cleaner history without merge commits.
Pros: Creates a linear history.
Cons: Can rewrite history, which might be problematic for shared branches.
git rebase <branch_name>
Git Tags and Releases
7. Git Tags and Releases:
Git tags are used to mark specific points in history, often used for releases. A tag points to a particular commit, allowing you to easily identify and reference a release.
Create a tag: Tags are typically created at significant points in a project’s development, like when releasing a version. git tag -a <tag_name> -m "Tag message" Example: git tag -a v1.0 -m "First official release"
Push tags: By default, tags are not pushed to remote repositories. You need to explicitly push tags. git push origin <tag_name> Example: git push origin v1.0
List tags: To view all the tags in a repository: git tag
Checkout a tag: To checkout a specific tag (e.g., a previous release): git checkout <tag_name> Example: git checkout v1.0
Releases: Releases in GitHub or GitLab use tags to provide a versioned snapshot of the code. When creating a release, you can associate it with a tag to specify the version being released.
Step 1: Set up a Remote Repository
To start, we’ll assume there’s a Git repository already hosted on a platform like GitHub or GitLab (you can create one there if needed).
For this example, the URL for the remote repository is:
https://github.com/username/SampleProject.git
Step 2: Clone the Repository
First, we’ll clone the remote repository to create a local copy.
After this, a new folder SampleProject will be created, and it will contain the files from the remote repository.
Step 3: Create a New Branch for Feature Development
Now that we have the repository, let’s create a new branch to work on a new feature. We’ll call this branch feature/add-new-feature.
cd SampleProject
git checkout -b feature/add-new-feature
The -b flag creates and checks out the new branch.
Step 4: Modify Files and Commit Changes
Let’s assume we add a new file or modify an existing one. For this example, we’ll modify a file called README.md.
Open README.md and add a line like: This is a new feature added to the project.
After saving the file, we need to stage the changes and commit them.
git add README.md # Stage the file
git commit -m "Add new feature description to README"
This command stages the changes and commits them with a descriptive message.
Step 5: Push the Branch to Remote Repository
Now that the feature is ready, let’s push the feature/add-new-feature branch to the remote repository.
git push origin feature/add-new-feature
This uploads your local branch to the remote repository, making it available for collaboration or review (such as in a pull request).
Step 6: Create a Pull Request (Optional)
If you’re working with a team, you would now go to the remote Git hosting platform (e.g., GitHub) and create a Pull Request (PR) to merge feature/add-new-feature into the main branch.
Step 7: Pull Latest Changes from the Remote Repository
While working on your feature, others may have pushed changes to the remote repository. To keep your local repository up to date, you can pull the latest changes from the main branch.
git checkout main # Switch to the main branch
git pull origin main # Pull latest changes from remote main branch
Step 8: Merge the Feature Branch into Main
Once the feature is approved (e.g., through a PR review), you can merge it back into the main branch. If you have already completed the PR, you’d merge the branches from the Git hosting platform interface. However, let’s do it manually on the command line:
git checkout main # Switch to the main branch
git merge feature/add-new-feature # Merge feature branch into main
At this point, your main branch includes the changes from feature/add-new-feature.
Step 9: Resolve Merge Conflicts (If Any)
If changes in the main branch and feature/add-new-feature branch conflict (e.g., both modified the same line in README.md), Git will mark the file as conflicted, and you’ll need to resolve the conflict.
You’ll see conflict markers in the file, like:
<<<<<<< HEAD
This is the content from the main branch.
=======
This is the content from the feature branch.
>>>>>>> feature/add-new-feature
You manually edit the file to keep the desired changes and remove the markers.
GDB GNU Debugger : GDB is a powerful tool used by developers to inspect what’s going on inside a running program or after it crashes. It helps you find and fix bugs by allowing you to pause execution, examine variables, inspect memory, and even step through lines of code.
The GNU Debugger (GDB) is a powerful tool used to debug programs written in various programming languages. It lets you inspect and modify memory, control the execution flow, set breakpoints, and much more to analyze and fix issues in your code.
GDB GNU Debugger
1. Installing GDB
In Red Hat Developer Toolset, the GNU Debugger is part of the devtoolset-9-gdb package, and it’s automatically installed along with the toolset. To get started with GDB, follow these installation steps:
If you’re using the devtoolset-9 toolchain, GDB is already included. Here’s how you can install the necessary packages:
To start debugging your program with GDB, use the following command:
$ scl enable devtoolset-9 'gdb fibonacci'
Once inside GDB, you’ll see a prompt where you can start debugging your program. To exit GDB, simply type:
(gdb) quit
4. Listing Source Code
To view the source code of the program you’re debugging, use the list command in GDB. It will show the first 10 lines of the code. You can also change the number of lines displayed:
(gdb) list
(gdb) set listsize 20 # Show 20 lines instead of 10
5. Setting Breakpoints
A breakpoint is a place where the program will stop, allowing you to inspect the state of your program. You can set a breakpoint at a specific line or function:
Once you’ve set breakpoints, you can run your program inside GDB:
(gdb) run
If your program needs arguments, you can pass them like this:
(gdb) run arg1 arg2
The program will stop at the first breakpoint or when it encounters an error.
7. Displaying Variable Values
To check the current value of a variable while debugging, use the print command:
(gdb) print variable_name
For example, after stopping at a breakpoint, you can print the value of a variable:
(gdb) print a
(gdb) print b
8. Continuing Execution
To continue the program after hitting a breakpoint, use the continue command:
(gdb) continue
If you want to skip a certain number of breakpoints or stop after a few lines of code, use:
(gdb) continue number
(gdb) step number
The step command allows you to execute a specific number of lines, which is useful when you’re debugging loops or functions.
Example Workflow
Compile the Program with Debug Info:$ scl enable devtoolset-9 'gcc -g -o fibonacci fibonacci.c'
Start Debugging with GDB:$ scl enable devtoolset-9 'gdb fibonacci'
Set Breakpoint at Line 10:(gdb) break 10
Run the Program:(gdb) run
Print Variable Values:(gdb) print a (gdb) print b
Continue Execution:(gdb) continue
Let’s work with a simple C code example to demonstrate the use of GDB.
Example C Program: factorial.c
#include <stdio.h>
int factorial(int n) {
if (n == 0 || n == 1) {
return 1;
}
return n * factorial(n - 1);
}
int main() {
int num = 5;
int result = factorial(num);
printf("Factorial of %d is %d\n", num, result);
return 0;
}
This program calculates the factorial of 5 and prints the result.
Steps to Debug Using GDB:
Compile the Program with Debug Information
To compile the C code with debugging symbols, we use the -g option in gcc.
gcc -g -o factorial factorial.c
This will produce an executable file named factorial.
Start GDB
To start GDB with the compiled program, use the following command:
gdb ./factorial
Set Breakpoints
We want to set a breakpoint at the factorial function to see the recursive calls.
To set a breakpoint at the factorial function, run the following in the GDB prompt:
(gdb) break factorial
Run the Program
Now, run the program inside GDB:
(gdb) run
The program will start, and GDB will pause at the first call to factorial.
Step Through the Code
To step through the code one line at a time, use the step command:
(gdb) step
This will take you inside the factorial function, and you can continue stepping through the function’s execution.
Display Variable Values
To check the value of the variables, such as n, you can use the print command. For example:
(gdb) print n
This will show the value of n at each step of the recursion.
Continue Execution
After reaching the breakpoint and checking variable values, you can continue execution until the next breakpoint (or the end of the program):
(gdb) continue
Exit GDB
Once you’re done, exit GDB by typing:
(gdb) quit
Expected Output
During the debugging session, GDB will allow you to inspect the recursive calls to factorial and the values of n at each step. Eventually, it will display the final result after the program reaches the print statement.
1. GDB Basics and Commands
What is GDB?
GDB is the GNU Debugger. It lets you:
Start your program and pause it anywhere.
View variable values at runtime.
Step through code line by line.
Set breakpoints (pause points).
Inspect memory and CPU registers.
How to Compile with Debug Info
Before using GDB, compile your code with debug symbols:
gcc -g main.c -o main
The -g flag tells the compiler to include debug information.
Starting GDB
gdb ./main
Common Commands
Command
Description
run
Starts the program
break <line/function>
Sets a breakpoint
next or n
Steps to next line (skips function calls)
step or s
Steps into a function
continue or c
Resumes execution
print <var>
Prints the value of a variable
list
Shows source code
quit
Exits GDB
2. Remote Debugging with GDB
Remote debugging is used to debug a program running on another system (like embedded Linux or RTOS).
Setup
On Target (with GDB server):
gdbserver :1234 ./app
On Host (your PC):
gdb ./app
(gdb) target remote <target-ip>:1234
Now you’re controlling the target program from your host machine.
3. Breakpoints, Watchpoints, Backtrace
Breakpoints
Stop execution at specific lines or functions:
(gdb) break main
(gdb) break 42 # line 42
Watchpoints
Automatically pause when a variable changes:
(gdb) watch counter
Backtrace
See the function call history (call stack):
(gdb) backtrace
This shows which functions were called and in what order.
4. Disassembly and Register Inspection
Disassemble Code
See the machine code for your program:
(gdb) disassemble main
View Registers
See CPU register values (great for low-level debugging):
(gdb) info registers
For ARM/MIPS/other architectures, you’ll see general-purpose and special registers.
5. Debugging on Bare-Metal & RTOS
Bare-Metal Debugging
Bare-metal means there’s no OS — you’re debugging directly on hardware (e.g., ARM Cortex-M microcontroller).
RTOS debugging is similar to bare-metal, but you may need:
RTOS-aware GDB scripts (for thread/task context)
Special memory maps
You can:
Pause execution
View current tasks
Inspect stack of each thread
GDB extensions/plugins like FreeRTOS-aware GDB scripts can show tasks and queues.
How GDB Interacts with Compiled Binaries
GDB (GNU Debugger) is a tool used to examine and control programs after they are compiled. When you compile a program, the compiler turns your human-readable source code into machine-readable binary code. GDB interacts with these compiled binaries by reading and controlling their execution.
Here’s how it works step-by-step:
Reading the Binary File GDB loads the compiled binary file (usually an executable) into memory. If the binary contains debugging information (generated using the -g flag during compilation), GDB can use this information to map machine code back to your original source code, including variables, functions, and line numbers.
Connecting to the Process GDB can either start a program directly or attach to an already running process. It uses system-level APIs to take control of the process execution.
Controlling Execution Once attached, GDB can pause program execution (breakpoints), step through code line-by-line (step/next), or continue execution. This allows programmers to inspect exactly how their code is running.
Inspecting Memory and Variables GDB reads the memory and register states of the running program. This lets you examine variable values, memory contents, and CPU registers to understand the program’s behavior.
Modifying Execution GDB can also change variable values, set new program counter positions, or modify registers while the program runs. This helps in testing fixes without recompiling.
Key takeaway: GDB bridges the gap between your compiled binary and the original source code, allowing you to inspect, control, and debug the program’s execution at a very deep level.
Breakpoints and Watchpoints in GDB
When debugging with GDB, you often need to pause the program or observe certain events to understand its behavior. That’s where breakpoints and watchpoints come in. They are both tools to stop or monitor a program during execution, but they work differently.
1. Breakpoints
A breakpoint is a marker you set at a specific line of code or function. When the program execution reaches that point, GDB pauses the program so you can inspect the state of the program.
Example use case: If your program crashes in a function, you can set a breakpoint at the function start to see exactly what happens before the crash.
How to set a breakpoint in GDB:
(gdb) break main # Break at the start of main()
(gdb) break 25 # Break at line 25 in the current file
When the program hits the breakpoint, GDB stops execution and gives control back to you.
2. Watchpoints
A watchpoint is like a dynamic watch on a variable or memory location. GDB pauses execution whenever the value of that variable or memory changes.
Example use case: If a variable is changing unexpectedly, you can set a watchpoint on it to find the exact point where the change happens.
How to set a watchpoint in GDB:
(gdb) watch x # Watch variable x
When the watched variable changes, GDB stops execution and shows where the change occurred.
Key Differences Between Breakpoints and Watchpoints
Feature
Breakpoint
Watchpoint
Purpose
Stop execution at a specific line or function
Stop execution when a variable or memory changes
Trigger
Reaching a specific location in code
Change in the value of a variable or memory
Usage
Used to inspect execution flow
Used to monitor specific variable changes
Performance
Low impact on performance
Higher performance cost because memory is monitored
In short:
Breakpoints → Stop at a specific point in code.
Watchpoints → Stop when data changes.
Summary
Feature
GDB Command
Set Breakpoint
break <line/function>
Step Through Code
next, step
Inspect Variable
print var
Remote Debug
target remote <ip:port>
View Registers
info registers
Disassemble
disassemble
Watch Variable
watch var
Backtrace
backtrace
Here’s a beginner-friendly, plagiarism-free, and uniquely written explanation of essential GDB commands, complete with simple descriptions and a few helpful tips.
Common GDB Commands You Should Know
Command
What It Does (Beginner-Friendly)
run or r
Starts the program from the beginning. Great for testing your code cleanly.
break or b
Puts a stop (breakpoint) at a specific line or function so you can pause there.
disable
Temporarily turns off a breakpoint without removing it. Useful for quick toggles.
enable
Turns a disabled breakpoint back on. Handy if you’re toggling breakpoints often.
next or n
Moves to the next line of code without entering into any called function.
step
Goes to the next line, but enters into functions to help debug them deeper.
list or l
Shows the source code around the current line or a specified location.
print or p
Shows the current value of a variable. Also great for checking expressions.
quit or q
Exits GDB. You’ll be asked to confirm if the program is still running.
clear
Removes all breakpoints, or just one if specified. Good for cleanup.
continue
Resumes program execution after hitting a breakpoint or stepping through code.
Example Session (Simple Workflow)
$ gdb ./my_program # Start GDB with your compiled program
(gdb) break main # Set a breakpoint at the beginning
(gdb) run # Start running the program
(gdb) next # Move to the next line
(gdb) print myVar # Check the value of a variable
(gdb) continue # Resume execution until next breakpoint
(gdb) quit # Exit when you're done
Frequently Asked Questions (FAQ)
1. What is GDB and why is it used?
GDB (GNU Debugger) is a powerful debugging tool used to analyze and debug programs written in languages like C, C++, and others. It helps developers inspect code, find bugs, check variable values, trace program execution, and understand crashes or unexpected behavior.
2. Is GDB only for C/C++ programs?
No! While GDB is widely used for C and C++, it also supports other languages like Ada, Fortran, Go, Rust, and more—depending on compiler support and integration.
3. How do I install GDB?
Linux: Use your package manager (e.g., sudo apt install gdb on Ubuntu).
macOS: Use Homebrew → brew install gdb.
Windows: Install via MinGW or download pre-built binaries from official sites.
4. Can GDB debug running processes?
Yes! GDB can attach to an already running process using the attach <pid> command, allowing you to debug without restarting the application.
5. What are breakpoints in GDB?
Breakpoints are markers you set in code to pause execution at specific lines or functions. They let you inspect program state, variables, and execution flow at precise points.
Example:
(gdb) break main
6. How do I run a program inside GDB?
Use the run command:
(gdb) run
Or pass arguments like:
(gdb) run arg1 arg2
7. What is a backtrace in GDB?
A backtrace (via the bt command) shows the call stack leading to the current point in execution. It’s very helpful for diagnosing where and how a program crashed.
8. Can GDB be used for remote debugging?
Yes. GDB supports remote debugging over serial ports, TCP/IP, or JTAG interfaces. You use target remote to connect to a remote GDB server.
9. Is GDB suitable for beginners?
Absolutely! While it has a learning curve, GDB is beginner-friendly once you grasp basic commands like break, run, next, step, print, and bt.
10. Are there graphical front-ends for GDB?
Yes. Tools like:
DDD (Data Display Debugger)
Eclipse CDT Debugger
Insight
GDB Dashboard (TUI enhancements)
These provide graphical interfaces that make debugging visually easier.
11. How can I debug core dumps with GDB?
If your program crashes and generates a core file, you can inspect it like this:
gdb <program> core
This lets you analyze the state of the program at the time of the crash.
12. Is GDB available for free?
Yes! GDB is completely free and open-source, distributed under the GNU General Public License (GPL).
13. What’s new in GDB for 2025?
(Replace this with your blog’s content if you’ve covered new GDB updates. For example:)
JTAG stands for Joint Test Action Group, which is the name of the group that initially developed the standard. Today, JTAG commonly refers to both the group and the test interface and protocol defined by the IEEE 1149.1 standard.
Originally created in the 1980s, JTAG was developed as a solution to a growing problem in electronics manufacturing: how to test complex circuit boards where physical access to all the pins and components was no longer possible.
Why Was JTAG Created?
As electronic components became smaller and more integrated, traditional testing methods like bed-of-nails testers or external probes couldn’t easily reach the pins or internal signals of components. JTAG was introduced to allow:
Testing of individual pins and board connections,
Debugging of embedded systems,
Programming of microcontrollers, FPGAs, CPLDs, and flash memory,
Diagnosing faults during development and manufacturing.
JTAG Is More Than Just Debugging and Programming
When most people think of JTAG, they associate it with debugging processors or programming FPGAs and CPLDs. That’s not wrong—but it’s only part of the story.
JTAG isn’t just about debugging. It isn’t just about programming either.
While you might know JTAG through tools that connect to a JTAG interface, such as debuggers or flash programmers, those tools typically use only one part of what JTAG has to offer: the four-wire communication protocol defined by the IEEE 1149.1 standard.
What Else Can JTAG Do?
JTAG was originally developed as a solution for testing circuit boards—specifically to overcome the limitations of traditional test methods like bed-of-nails testers. These older methods required physical access to every pin or needed complex custom setups for functional testing.
To solve this, IEEE created the concept of a Test Access Port (TAP), which uses four signals (TCK, TMS, TDI, TDO) to interact with special test registers inside chips.
The key test register introduced by this standard is the Boundary Scan Register (BSR).
What Is a Boundary Scan Register?
The Boundary Scan Register sits at the edges (or “boundaries”) of a chip, between its functional logic core and the actual pins that connect it to a board. That’s why JTAG testing is often called “boundary scan” testing.
These registers are made up of individual cells that can:
Operate in functional mode, where they don’t interfere with normal chip behavior.
Operate in test mode, where they take control of the chip’s input/output pins.
In test mode, these boundary scan cells allow us to:
Drive specific values onto the board’s signal lines (outputs),
Read the values present on those lines (inputs).
How Does This Help in Testing?
Here’s the powerful part: When JTAG is used in test mode, it allows engineers to control and observe signals on a PCB without booting the system or loading firmware. The device doesn’t need to be configured—it just needs to support boundary scan.
This means:
You can test for short circuits, opens, and miswirings,
You can run tests without needing full firmware or software,
It reduces the need for physical access to test points.
Two Main Ways to Use JTAG for Testing
Connection Testing This basic method checks for short circuits and open connections by using only the JTAG-capable devices and their pins. It provides good coverage using the board’s layout and JTAG features.
Extended Testing (with non-JTAG devices) Tools like XJTAG can go further by using JTAG-enabled chips to talk to non-JTAG devices (e.g., DDR RAM, Flash). This allows testing of more complex components using the existing JTAG infrastructure.
JTAG is much more than a tool for programming chips or debugging firmware. It’s a powerful hardware test interface that helps engineers:
Test boards without physical probes,
Check soldering and connectivity,
Debug hardware issues early in development,
Communicate with various components through a simple 4-pin interface.
So next time you hear “JTAG,” remember: It’s not just a port—it’s a gateway to deep-level access and testing.
💛 Support Embedded Prep
If you find our tutorials helpful and want to support our mission of sharing high-quality embedded system knowledge, you can contribute by buying us a coffee.
Every small contribution helps us keep creating valuable content for learners like you. ☕
Thank you for your support — it truly keeps Embedded Prep growing. 💻✨
1. Introduction
When working with embedded systems, hardware debugging, or board-level testing, JTAG is a name that comes up often. But what exactly is it?
JTAG stands for Joint Test Action Group—the name of the group that developed the standard. It’s an interface and protocol that allows you to test, debug, and program devices on a circuit board, even when they are soldered down and inaccessible through traditional means.
2. What is JTAG?
At its core, JTAG is a standard for verifying designs and testing printed circuit boards (PCBs) after manufacture. It provides a standardized interface to communicate with chips using just a few pins.
JTAG was standardized as IEEE 1149.1 in 1990 and is commonly used in embedded systems, FPGA programming, microcontroller debugging, and boundary scan testing.
3. Why Was JTAG Introduced?
Before JTAG, engineers used bed-of-nails testers or manually probed signals on PCBs. These methods had major drawbacks:
JTAG solved this by embedding test logic inside chips, allowing for internal signal monitoring and control through a serial interface—no need to physically touch internal nodes!
4. How Does JTAG Work?
JTAG enables access to a device’s internal functions using a serial protocol and a Test Access Port (TAP). This port can:
Control internal registers
Access memory
Perform boundary scans
Program flash memory
The TAP connects to a chain of devices called a JTAG daisy chain. Devices in the chain share the same control signals, but each has its own data path.
The core components inside a JTAG-enabled device include:
TAP Controller – Controls the JTAG state machine
Instruction Register (IR) – Decides what operation to perform (e.g., read ID, boundary scan)
Data Registers (DR) – Used to shift in/out data
5. JTAG Pinout and Signals
JTAG usually uses 4 or 5 pins:
Pin Name
Full Form
Description
TDI
Test Data In
Serial data input into the JTAG chain
TDO
Test Data Out
Serial data output from the JTAG chain
TCK
Test Clock
Provides the clock for synchronizing data
TMS
Test Mode Select
Controls the state of the TAP controller
TRST
Test Reset (optional)
Resets the JTAG state machine (not always used)
6. Common Use Cases of JTAG
Boundary Scan Testing
Check connectivity between pins and trace faults without physical probing.
In-System Programming (ISP)
Program flash memory, FPGAs, CPLDs, and MCUs via JTAG.
Debugging Embedded Systems
Set breakpoints, inspect registers, view memory, and single-step through code.
Hardware Bring-Up
Access low-level hardware registers before firmware is ready.
7. JTAG in Embedded Systems
JTAG is essential for developers working on ARM Cortex, STM32, ESP32, or custom SoCs. It allows you to:
Flash firmware without bootloader
Debug without printf()
Perform post-silicon validation
Example: JTAG with STM32
Using an ST-Link or J-Link programmer, you can connect to the STM32 via JTAG or SWD (Serial Wire Debug, a 2-wire variant) and debug using tools like OpenOCD + GDB or STM32CubeIDE.
8. Tools and Software for JTAG
Hardware Debug Probes:
SEGGER J-Link
ST-Link (for STM32)
TI XDS110 (for TI MCUs)
FTDI-based cables (DIY options)
Software:
OpenOCD (Open On-Chip Debugger) – Popular open-source JTAG interface
GDB – GNU debugger for step-through debugging
Vendor IDEs – STM32CubeIDE, IAR, Keil MDK, Code Composer Studio
9. Advantages and Limitations
Advantages
Access internal registers and memory
Non-intrusive testing and debugging
Programming without bootloader
Works even when the system is not fully booted
Limitations
Not supported by all chips
Configuration can be complex for beginners
Risk of bricking if improperly used
JTAG interfaces can be disabled for security in some products
10. Conclusion
JTAG is a powerful and essential interface for hardware debugging, device testing, and embedded system development. While it may seem complex at first, learning JTAG opens the door to low-level system access, deep debugging, and smoother hardware bring-up processes.
If you’re working with microcontrollers, FPGAs, or custom PCBs, understanding JTAG is a must-have skill.
FAQ – Master JTAG (Joint Test Action Group): A Beginner-Friendly, In-Depth Guide (2025)
1. What is JTAG and why should I learn it?
JTAG (Joint Test Action Group) is a standard (IEEE 1149.1) used for testing, programming, and debugging hardware—mainly microcontrollers, FPGAs, and CPUs. Learning JTAG is essential for embedded developers, hardware engineers, and system testers as it gives direct access to chip internals, enabling tasks like:
Boundary-scan testing (fault detection on PCBs)
Flashing firmware directly
Debugging software running on target boards
2. What are the typical use cases of JTAG?
Hardware testing: Identify faulty components or soldering defects.
Firmware flashing: Load firmware into non-volatile memory without a bootloader.
Real-time debugging: Step through code, inspect registers, memory, and control execution.
Board bring-up: Debug and validate hardware during prototype development.
3. Which hardware tools do I need for JTAG?
You typically need:
A JTAG debugger/programmer (e.g., SEGGER J-Link, ST-LINK, OpenOCD-compatible dongles)
A target device that supports JTAG (e.g., STM32, ARM Cortex-M, Xilinx FPGAs)
4. What are the standard JTAG pinouts and signals?
Typical JTAG signals include:
TDI (Test Data In) – Data input to the target
TDO (Test Data Out) – Data output from the target
TCK (Test Clock) – Clock signal
TMS (Test Mode Select) – Controls state transitions
TRST (optional) – Test Reset
GND – Ground
Vref – Reference voltage (for logic level compatibility)
5. How does JTAG work internally?
JTAG uses a TAP controller (Test Access Port), which moves through states based on the TMS and TCK lines. It shifts data into registers (e.g., instruction register, data register) and enables control over internal signals without requiring CPU code execution.
6. Is JTAG only for testing hardware?
No. While JTAG was initially designed for boundary-scan testing, it evolved to support:
Flash programming
Low-level debugging
Chip-level introspection
Reset and boot control
7. Can I use JTAG with open-source tools?
Yes. Tools like:
OpenOCD (Open On-Chip Debugger) for programming and debugging
GDB for source-level debugging with breakpoints and watchpoints
UrJTAG for boundary-scan and low-level testing
These tools are often free and widely supported.
8. What’s the difference between JTAG and SWD (Serial Wire Debug)?
JTAG: 4–5 signals; full IEEE 1149.1 standard; widely supported.
SWD: ARM-specific 2-wire protocol; lighter and faster; used on Cortex-M devices. Both support debugging and programming, but SWD is preferred for space-constrained designs.
9. What are boundary-scan and chain configurations in JTAG?
Boundary-scan: Allows testing of I/O pins without booting the processor.
JTAG chain: Multiple devices can be connected in series (TDI → TDO) using a single JTAG interface. Each device has a unique ID and is accessed through a specific instruction.
10. What are common JTAG errors and how do I fix them?
Error
Cause
Fix
Target not found
Wrong pinout, bad solder
Check wiring, use multimeter
Device ID mismatch
Wrong chip selected
Check chain or update config
No response to TCK/TMS
Dead chip or damaged port
Try alternate device or port
OpenOCD config failed
Wrong interface/chip
Double-check .cfg files
11. Can JTAG be used on production devices?
Yes, but JTAG is often disabled or locked for security reasons in production devices. Secure provisioning may require unlocking or access keys.
12. Where can I practice JTAG debugging hands-on?
Start with:
STM32 Nucleo or Discovery boards
ESP32 DevKit
Raspberry Pi with GPIO for JTAG
FPGAs like Xilinx or Intel (with USB Blaster, Platform Cable)
Use OpenOCD + GDB or manufacturer IDEs (STM32CubeIDE, Xilinx Vivado, etc.).
13. What are the career benefits of learning JTAG?
Mastering JTAG gives you an edge in:
Embedded software development
Board-level diagnostics
Hardware testing and verification
Secure firmware deployment It’s a key skill for Embedded Engineers, Firmware Developers, and Test Engineers.
You can also Visit other tutorials of Embedded Prep
SWD Serial Wire Debug : When working with microcontrollers, debugging is a key part of development. One common way to debug embedded systems is using SWD, short for Serial Wire Debug. It’s a modern, efficient way to communicate with a microcontroller during development.
Let’s break it down in a simple way.
What is SWD Serial Wire Debug?
Serial Wire Debug (SWD) is a two-wire protocol developed by ARM for debugging ARM Cortex-M microcontrollers. It is an alternative to the older JTAG protocol, which uses more pins.
SWD allows you to:
Load firmware into the microcontroller.
Set breakpoints and step through code.
Read and write memory.
Monitor and control the processor state.
SWD Serial Wire Debug vs JTAG
Feature
SWD (Serial Wire Debug)
JTAG
Wires
2
4-5
Speed
Fast
Fast
Pin Usage
Low (good for small MCUs)
Higher (more GPIO needed)
Complexity
Simpler
More complex
Debug Access
Full access
Full access
So, SWD is preferred when you have limited pins available and are working with ARM-based chips.
How SWD Serial Wire Debug Works
SWD uses only 2 main signals:
SWDIO – Serial Wire Debug Input/Output Acts like data line (similar to SDA in I2C).
SWCLK – Serial Wire Clock Acts like the clock line (similar to SCL in I2C).
Optionally, you might also have:
nRESET – To reset the microcontroller from the debugger (optional).
GND – A common ground between your debug tool and target board (mandatory).
Tools Involved
To use SWD, you need:
A microcontroller that supports SWD (e.g., STM32, NXP, etc.).
A debug probe, such as:
ST-Link (for STM32)
J-Link (Segger)
CMSIS-DAP
A debugger software like:
STM32CubeIDE
Keil uVision
OpenOCD with GDB
SWD Serial Wire Debug Pinout Example (STM32)
Here’s a common SWD pinout on STM32 boards:
Pin Name
Function
SWDIO
Data
SWCLK
Clock
GND
Ground
3.3V
Power supply
NRST
Reset (optional)
Why Use SWD?
👨💻 Easy Debugging: Load, step, break, and inspect code easily.
🧠 Access RAM/Flash: Read/write memory and registers.
🔄 Flash Programming: Upload firmware via the debug interface.
📉 Fewer Pins: Perfect for space-constrained designs.
🧰 Low-Cost Tools: Many low-cost debug probes available.
Real-Life Use Case
Let’s say you’re working with an STM32 microcontroller. You want to flash your code and debug it:
Connect ST-Link to SWDIO, SWCLK, GND, and optionally NRST.
Open STM32CubeIDE and start a debug session.
You can now:
Set breakpoints in code.
See variables change in real time.
Step through the program.
Prerequisites
Before you start, make sure you have:
✅ A microcontroller board (e.g., STM32F103, STM32 Nucleo).
✅ A debug probe (e.g., ST-Link, J-Link, or CMSIS-DAP).
✅ A PC with debugging software installed (e.g., STM32CubeIDE, Keil uVision, OpenOCD + GDB).
✅ Wires or a USB cable to connect the debugger.
✅ Basic USB driver for the debug probe installed.
💛 Support Embedded Prep
If you find our tutorials helpful and want to support our mission of sharing high-quality embedded system knowledge, you can contribute by buying us a coffee.
Every small contribution helps us keep creating valuable content for learners like you. ☕
Thank you for your support — it truly keeps Embedded Prep growing. 💻✨
Step-by-Step: Connecting SWD
1. Identify SWD Pins on the Microcontroller
Look for the following pins on your MCU or dev board:
SWDIO – Data line
SWCLK – Clock line
GND – Ground
NRST – (Optional, Reset line)
VCC – Target voltage reference (often 3.3V)
You can find these in the datasheet or board pinout diagram.
2. Connect the Debug Probe
Match these pins between the debugger and the target board:
Debugger Pin
Target Board Pin
SWDIO
SWDIO
SWCLK
SWCLK
GND
GND
NRST (opt.)
NRST
VCC (ref.)
3.3V or 5V
Ensure you connect GND properly. Without a common ground, SWD won’t work.
3. Power the Target
Some debug probes (like ST-Link) can provide power.
Or power the board externally via USB or battery.
Step-by-Step: Debugging
4. Open Your IDE or Debug Software
Examples:
STM32CubeIDE for STM32
Keil uVision
VS Code with GDB + OpenOCD
Segger Ozone for J-Link
5. Create or Open a Project
Write or import your embedded C/C++ code.
Make sure the correct MCU is selected.
Configure the debugger settings if needed.
6. Build Your Code
Click Build / Compile.
Ensure the project compiles without errors.
7. Start Debug Session
Click Debug (Bug icon).
Your IDE will flash the firmware to the MCU via SWD.
It will then pause at main() (or wherever you’ve set breakpoints).
8. Debugging Features You Can Use
Once debugging starts, you can:
🔴 Set breakpoints
🔁 Step over/into code
🧠 Watch variables and memory
🛑 Halt/resume the target
🔍 Monitor registers and peripherals
⏹️ 9. Stop Debugging
Click Terminate or Stop Debugging in the IDE.
Summary
Step
Action
1
Identify SWDIO, SWCLK, GND, etc.
2
Connect debug probe to target board
3
Power the board
4
Open IDE and load project
5
Build the code
6
Start debug session
7
Set breakpoints, inspect memory
8
Stop debug session
You can also Visit other tutorials of Embedded Prep
