RTOS - Task Synchronization

Exp No: 13
Date:
Designing with RTOS: Task Synchronization Techniques
Introduction:
Task synchronization is crucial in Real-Time Operating Systems (RTOS) to prevent conflicts
in resource access and ensure the proper sequence of operations across processes. This study
delves into various synchronization techniques employed in RTOS environments, focusing on
mutual exclusion mechanisms such as busy waiting and sleep-wake up policies.
Mutual Exclusion:
Mutual exclusion ensures exclusive access to shared resources, preventing concurrent access
by multiple processes. One common implementation is through the use of lock variables, where
processes check the lock's state before entering critical sections. This mechanism can be
implemented using busy waiting or sleep-wake up policies.
Busy Waiting:
Busy waiting relies on continuously checking the state of a lock variable until it becomes
available. While simple to implement, it poses challenges due to the lack of atomic instructions
for lock management. The use of low-level instructions like CMPXCHG on processors such
as Intel architectures facilitates atomic operations, preventing synchronization issues during
context switches.
Sleep & Wakeup:
Alternatively, the sleep-wakeup policy involves processes waiting for access to a critical
section to sleep until notified by the owning process. This technique is OS kernel-dependent
and can be implemented using semaphores. Binary semaphores ensure exclusive resource
access, while counting semaphores limit resource usage to a fixed number of processes.
Binary Semaphore:
Binary semaphores allow only one process to own the semaphore at a time, ensuring exclusive
resource access. The semaphore's state transitions between signaled (available) and non-
signaled (owned) states, facilitating mutual exclusion. Implementation details may vary
depending on the underlying OS kernel, with some referring to binary semaphores as mutexes.
Mutual Exclusion Semaphore:
Certain RTOS, like VxWorks and uC/OS-II, offer a specialized implementation called mutual
exclusion semaphores to address priority inversion issues. These semaphores adjust task
priorities dynamically, ensuring that high-priority tasks waiting for access to a resource are not
preempted by lower-priority tasks holding the semaphore.
Conclusion:
Task synchronization techniques are fundamental in RTOS environments to prevent conflicts
in resource access and ensure the proper sequence of operations. By understanding and
implementing mutual exclusion mechanisms such as busy waiting and sleep-wake up policies,
developers can design robust and efficient RTOS-based systems.
 Debugging Techniques
Exp No: 14
Date:
Debugging an Embedded System
Debugging an embedded system shares similarities with debugging host-based applications.
However, many embedded systems cannot be debugged effectively unless they are operating
at full speed. Therefore, debugging often involves using a host computer. Typically, the
debugger comprises two components: a debug kernel in the target system and a host application
that communicates with it, managing source databases and symbol tables.
Requirements for Debugging
Three essential requirements for debugging an embedded or real-time system include:
1. Run Control: The ability to start, stop, peek, and poke the processor and memory.
2. Memory Substitution: Replacing ROM-based memory with RAM for rapid and easy
code download, debug, and repair cycles.
3. Real-Time Analysis: Following code flow in real-time with real-time trace analysis.
Model Debugging System
A model debugging system consists of two processes: the test program and the debugger. These
processes run concurrently, with one part of the debugger executing on the host and the other
on the target machine. To ensure non-intrusiveness, code execution only occurs at breakpoints,
with the debugger running as a separate process and provided with a separate execution unit.
Debugging Tools
Various debugging options exist for embedded system development, including simulators,
in-circuit emulators (ICE), and remote target processors. Simulators simulate the functionality
and instruction set of the target processor, providing valuable debugging insights during the
early
stages of development. Remote debuggers monitor and control embedded software over a
communication link, while ICEs replace the target processor, allowing examination of the
processor's state while the program is running.
Difference in Emulator and ICE
While both emulators and ICEs serve as debugging tools, they differ in hardware architecture
and functionality. Emulators emulate the target system with extended memory and code
downloading ability, while ICEs use a separate circuit with a card that connects to the target
processor through a socket.
Hardware Emulators
Hardware emulators, such as Net ROM, are specialized devices designed to supplement
software-only debugging solutions. They emulate the target system's ROM device, providing
high-speed access to RAM for code modification and debugger breakpoints.
Benefits and Drawbacks of Debugging with Emulator
Emulators offer superior graphics quality and additional features compared to original
hardware, making them effective debugging systems. They save states and maintain the
original look, feel, and behavior of the embedded system. However, the cost of developing an
emulator is high, and it requires better hardware than the original system. Despite these
drawbacks, emulators prove to be a cost-efficient solution over time and enable software
exclusive to one system to be used on another.
Introduction to Debugging Tools of Embedded Systems
Embedded systems play a crucial role in various industries, from consumer electronics to
automotive and industrial automation. These systems consist of hardware and software
components designed to perform specific functions within a constrained environment.
Functionalities and Features of Debugging Tools
Each type of debugging tool offers specific functionalities and features tailored to different
stages of the development lifecycle. Some common functionalities and features of debugging
tools include:
● Breakpoints
● Step-by-Step Execution
● Variable Inspection
● Call Stack Navigation
● Memory Inspection
● Trace Analysis
● Performance Profiling
Best Practices for Debugging Embedded Systems
Effective debugging in embedded systems requires a systematic approach and adherence to
best practices. Some key best practices for debugging embedded systems include:
● Use of Version Control
● Unit Testing
● Integration Testing
● Regression Testing
● Use of Debugging Tools
Conclusion
Debugging is an integral part of embedded system development, ensuring that software
operates correctly and reliably on target hardware. Effective debugging requires the use of
specialized tools and techniques tailored to the unique challenges of embedded systems. By
leveraging debugging tools such as source-level debuggers, simulators, and analyzers,
developers can identify, analyze, and rectify software bugs efficiently, leading to the
development of high-quality and reliable embedded systems. Adherence to best practices such
as version control, unit testing, integration testing, and regression testing further enhances the
debugging process, enabling developers to deliver robust and efficient embedded solutions
across various applications and industries.
 Introduction to debugging tools of Embedded System
Exp No: 15
Date:
Before the era of on-chip debugging, software developers relied heavily on pricey In-
Circuit Emulators (ICE) for testing applications on microcontrollers. However, as modern
microcontrollers advanced with high clock rates and compact, high-pin count packages,
adapting traditional ICE technology became impractical.
Today's microcontrollers incorporate on-chip debug logic, granting controlled access
to memory, CPU registers, and program execution without the need for costly external devices.
This on-chip debug logic, standard in production devices and accessed via a standard JTAG
interface, is deliberately simplified to avoid additional chip costs.
In the landscape of software stacks for embedded systems, a predominant trend is the utilization
of a gdbserver interface, which in turn exposes the "GDB Remote Serial Protocol" on one end
and communicates with the interfacing microcontroller (MCU) through the requisite debug
probe protocol on the other. This setup is prevalent across various development environments,
including Eclipse-based IDEs such as NXP's MCUXpresso, STM32CubeIDE, TrueSTUDIO,
and WICED-Studio IDE. Even though developers may interact with these IDEs, the debug
interface often operates through a gdbserver in the background.
This standardized approach streamlines the debugging process by providing a consistent
interface for developers to interact with, regardless of the specific IDE or hardware being used.
By leveraging gdbserver, developers can access the extensive debugging capabilities offered
by GDB (GNU Debugger) while seamlessly interfacing with the target MCU via the debug
probe protocol. This integration enhances efficiency and flexibility in embedded software
development, enabling developers to focus more on coding and debugging their applications.
Here's an introduction to some common debugging tools used in embedded systems
development:
1. Integrated Development Environments (IDEs)
2. In-Circuit Emulators (ICE)
3. JTAG Debuggers
4. Serial Debuggers
5. Logic Analyzers
6. RTOS-aware Debuggers
7. Probe Debuggers
8. Software Debugging Tools

These debugging tools are instrumental in the development lifecycle of embedded systems,
empowering developers to detect and rectify issues efficiently, ensuring the functionality,
performance, and reliability of embedded devices.
 Debugging Tool Description Features
Integrated Comprehensive platforms for embedded Code editing, compilation,
Development software development. Examples include debugging, deployment, project
Environments (IDEs) Eclipse, Keil µVision, and IAR management.
Embedded Workbench.
In-Circuit Emulators Devices for real-time debugging of Hardware breakpoints, trace
(ICE) software on target hardware. capabilities, real-time monitoring
of CPU registers and memory.
JTAG Debuggers Interface with the JTAG port of Setting breakpoints, single-
microcontrollers for debugging purposes. stepping, memory examination.
Serial Debuggers Communicate with embedded systems Debug message transmission,
via serial interfaces (e.g., UART, SPI, remote analysis.
I2C) for sending debug messages to a host
computer.
Logic Analyzers Capture and display digital signals in Visualizing communication
embedded systems for visualization and protocols, detecting timing issues.
analysis of digital circuit behavior.
RTOS-aware Provide insights into the behavior of Task scheduling visualization,
Debuggers embedded software running on RTOS, resource usage monitoring.
facilitating task scheduling visualization
and resource monitoring.
Probe Debuggers Interface with microcontroller debug Flash programming, memory
ports to offer capabilities such as flash access, real-time debugging.
programming, memory access, and real-
time debugging.
Software Debugging Software-based tools like GDB (GNU Setting breakpoints, inspecting
Tools Debugger) for command-line debugging variables, tracing program
of embedded software. execution.

Core Sight is the debug technology used in Cortex-M3 processor based microcontrollers. A
low-cost JTAG adapter (for example the Keil ULINK2) is all that is required to interface to the
Core Sight on-chip debug unit. In addition to the trace features, the Core Sight unit implements
additional break registers and provides on-the-fly memory access during program execution
without additional software overhead.
Fig : Flow to identify CoreSight debug infrastructure
To identify the Cortex-M3 processor within the CoreSight system, ARM recommends that a
debugger perform the following actions:
1. Locate and identify the Cortex-M3 ROM table using its CoreSight identification
2. Follow the pointers in that Cortex-M3 ROM table namely System Control Space (SCS),
Breakpoint unit (BPU) and Data watch point unit (DWT).
Core debug is an optional component. If core debug is removed then halt mode debugging is
not supported, and there is no halt, stepping, or register transfer functionality. Debug monitor
mode is still supported.
 Study on debugging techniques of an Embedded System using
various tools like probes, logical analyser, debuggers and simulators
Exp No: 16

Date :

Some of the debugging tools in practice are:

1. Integrated Development Environments (IDEs): IDEs like Keil uvision ,Eclipse,
Visual Studio Code, and IAR Embedded Workbench provide a comprehensive
environment for writing, compiling, debugging, and deploying embedded software.
They often include features such as code editors, compilers, debuggers, and project
management tools.

Fig: Keil Debug support

2. In-Circuit Emulators (ICE): ICE devices allow developers to debug software on the
actual hardware in real-time. They provide advanced features such as hardware
breakpoints, trace capabilities, and real-time monitoring of CPU registers and memory.
3. In-Circuit Debuggers (ICD): Similar to ICE, ICD tools enable developers to debug
code on the target hardware. However, they may not offer as many advanced features
as ICE devices and are often more affordable.
4. JTAG Debuggers: Joint Test Action Group (JTAG) debuggers interface with the
JTAG port of microcontrollers to provide debugging capabilities. They typically
support features like setting breakpoints, single-stepping through code, and examining
memory contents. The µVision Debugger connects to a Cortex-M3 processor-based
microcontroller using the ULINK2 USB-JTAG Adapter.ULINK2 allows Flash
programming and hardware debugging and supports all operating modes of the Core
Sight on-chip debug unit.
 Figure : ULINK2 JTAG Adapter connected to Target Hardware

5. Serial Debuggers: Serial debuggers, also known as UART debuggers, communicate

with embedded systems through serial interfaces like UART, SPI, or I2C. They allow
developers to send debug messages from the embedded system to a host computer for
analysis.
6. Logic Analyzers: Logic analyzers capture and display digital signals in embedded
systems, allowing developers to visualize and analyze the behavior of digital circuits.
They are useful for debugging communication protocols, timing issues, and signal
integrity problems.

Figure 4: Logic Analyze View of variable changes that are provided by data trace records.

7. Probe Debuggers: Probe debuggers, such as Segger J-Link and ST-Link, interface
with the debug ports of microcontrollers to provide debugging capabilities. They
support features like flash programming, memory access, and real-time debugging.
8. Software Debugging Tools: Software-based debugging tools, such as GDB (GNU
Debugger), provide a command-line interface for debugging embedded software. They
support features like setting breakpoints, inspecting variables, and tracing program
execution.
9. RTOS-aware Debuggers: Real-Time Operating System (RTOS) aware debuggers
provide insights into the behavior of embedded software running on an RTOS. They
allow developers to visualize task scheduling, monitor resource usage, and debug multi-
threaded applications. Keil RTX5 integrates multiple mechanisms that provide full
visibility into RTOS operation and thus speed up debugging of potential problems and
assist in program optimization.

Fig: Keil RTX5 RTOS aware debugger

10. Trace Tools: Trace tools capture and analyze trace data generated by embedded
systems during program execution. They provide insights into the sequence of events,
timing information, and performance metrics, facilitating debugging and optimization
of embedded software.

Fig : Trace Record window for selective review of all Cortex-M3 trace information