Editing Embedded system (section)

==Debugging==
Embedded [[debugging]] may be performed at different levels, depending on the facilities available. Considerations include: does it slow down the main application, how close is the debugged system or application to the actual system or application, how expressive are the triggers that can be set for debugging (e.g., inspecting the memory when a particular [[program counter]] value is reached), and what can be inspected in the debugging process (such as, only memory, or memory and registers, etc.).

From simplest to most sophisticated debugging techniques and systems are roughly grouped into the following areas:
* Interactive resident debugging, using the simple shell provided by the embedded operating system (e.g. Forth and Basic)
* Software-only debuggers have the benefit that they do not need any hardware modification but have to carefully control what they record in order to conserve time and storage space.<ref>{{Cite book |last1=Tancreti |first1=Matthew |last2=Sundaram |first2=Vinaitheerthan |last3=Bagchi |first3=Saurabh |last4=Eugster |first4=Patrick |title=Proceedings of the 14th International Conference on Information Processing in Sensor Networks |chapter=TARDIS |date=2015 |series=IPSN '15 |location=New York, NY, USA |publisher=ACM |pages=286–297 |doi=10.1145/2737095.2737096 |isbn=9781450334754 |s2cid=10120929}}</ref>
* External debugging using logging or serial port output to trace operation using either a monitor in flash or using a debug server like the [[Remedy Debugger]] that even works for heterogeneous [[multicore]] systems.
* An in-circuit debugger (ICD), a hardware device that connects to the microprocessor via a [[JTAG]] or [[Nexus (standard)|Nexus]] interface.<ref>{{Cite book|last1=Tancreti|first1=Matthew|last2=Hossain|first2=Mohammad Sajjad|last3=Bagchi|first3=Saurabh|last4=Raghunathan|first4=Vijay|title=Proceedings of the 9th ACM Conference on Embedded Networked Sensor Systems |chapter=Aveksha |date=2011|series=SenSys '11|location=New York, NY, USA|publisher=ACM|pages=288–301|doi=10.1145/2070942.2070972|isbn=9781450307185|s2cid=14769602}}</ref> This allows the operation of the microprocessor to be controlled externally, but is typically restricted to specific debugging capabilities in the processor. 
* An [[in-circuit emulator]] (ICE) replaces the microprocessor with a simulated equivalent, providing full control over all aspects of the microprocessor.
* A complete [[emulator]] provides a simulation of all aspects of the hardware, allowing all of it to be controlled and modified, and allowing debugging on a normal PC. The downsides are expense and slow operation, in some cases up to 100 times slower than the final system.
* For SoC designs, the typical approach is to verify and debug the design on an FPGA prototype board. Tools such as Certus<ref>{{cite web |url=http://www.eejournal.com/archives/articles/20121030-tektronix/ |title=Tektronix Shakes Up Prototyping, Embedded Instrumentation Boosts Boards to Emulator Status |publisher=Electronic Engineering Journal |date= 2012-10-30 |access-date=2012-10-30}}</ref> are used to insert probes in the FPGA implementation that make signals available for observation. This is used to debug hardware, firmware and software interactions across multiple FPGAs in an implementation with capabilities similar to a logic analyzer.

Unless restricted to external debugging, the programmer can typically load and run software through the tools, view the code running in the processor, and start or stop its operation. The view of the code may be as [[high-level programming language]], [[assembly code]] or mixture of both.

===Tracing===
Real-time operating systems often support [[tracing (software)|tracing]] of operating system events. A graphical view is presented by a host PC tool, based on a recording of the system behavior. The trace recording can be performed in software, by the RTOS, or by special tracing hardware. RTOS tracing allows developers to understand timing and performance issues of the software system and gives a good understanding of the high-level system behaviors. Trace recording in embedded systems can be achieved using hardware or software solutions. Software-based trace recording does not require specialized debugging hardware and can be used to record traces in deployed devices, but it can have an impact on CPU and RAM usage.<ref>{{Citation |last1=Kraft |first1=Johan |title=Trace Recording for Embedded Systems: Lessons Learned from Five Industrial Projects |date=2010 |url=http://link.springer.com/10.1007/978-3-642-16612-9_24 |work=Runtime Verification |volume=6418 |pages=315–329 |editor-last=Barringer |editor-first=Howard |place=Berlin, Heidelberg |publisher=Springer Berlin Heidelberg |language=en |doi=10.1007/978-3-642-16612-9_24 |isbn=978-3-642-16611-2 |access-date=2022-08-16 |last2=Wall |first2=Anders |last3=Kienle |first3=Holger |editor2-last=Falcone |editor2-first=Ylies |editor3-last=Finkbeiner |editor3-first=Bernd |editor4-last=Havelund |editor4-first=Klaus|url-access=subscription }}</ref> One example of a software-based tracing method used in RTOS environments is the use of empty [[Macro (computer science)|macros]] which are invoked by the operating system at strategic places in the code, and can be implemented to serve as [[Hooking|hooks]].

===Reliability===
Embedded systems often reside in machines that are expected to run continuously for years without error, and in some cases recover by themselves if an error occurs. Therefore, the software is usually developed and tested more carefully than that for personal computers, and unreliable mechanical moving parts such as disk drives, switches or buttons are avoided.

Specific reliability issues may include:
* The system cannot safely be shut down for repair, or it is too inaccessible to repair. Examples include space systems, undersea cables, navigational beacons, bore-hole systems, and automobiles.
* The system must be kept running for safety reasons. Reduced functionality in the event of failure may be intolerable. Often backups are selected by an operator. Examples include aircraft navigation, reactor control systems, safety-critical chemical factory controls, train signals.
* The system will lose large amounts of money when shut down: Telephone switches, factory controls, bridge and elevator controls, funds transfer and market making, automated sales and service.

A variety of techniques are used, sometimes in combination, to recover from errors—both software bugs such as [[memory leak]]s, and also [[soft error]]s in the hardware:
* [[watchdog timer]] that resets and restarts the system unless the software periodically notifies the watchdog subsystems
* Designing with a [[trusted computing base]] (TCB) architecture ensures a highly secure and reliable system environment<ref>{{cite journal |url=http://c59951.r51.cf2.rackcdn.com/5557-528-heiser.pdf |archive-url=https://web.archive.org/web/20141129070740/http://c59951.r51.cf2.rackcdn.com/5557-528-heiser.pdf |archive-date=2014-11-29 |url-status=live |title=Your System is secure? Prove it! |first1=Gernot |last1=Heiser |date=December 2007 |volume=2 |issue=6 |pages=35–8 |journal=[[;login:]]}}</ref>
* A [[hypervisor]] designed for embedded systems is able to provide secure encapsulation for any subsystem component so that a compromised software component cannot interfere with other subsystems, or privileged-level system software.<ref>{{cite book|last1=Moratelli|first1=C|last2=Johann|first2=S|last3=Neves|first3=M|last4=Hessel|first4=F|title=Proceedings of the 27th International Symposium on Rapid System Prototyping: Shortening the Path from Specification to Prototype|chapter=Embedded virtualization for the design of secure IoT applications|pages=2–6|date=2016|chapter-url=https://ieeexplore.ieee.org/document/7909116|access-date=2 February 2018|doi=10.1145/2990299.2990301|isbn=9781450345354|s2cid=17466572}}</ref> This encapsulation keeps faults from propagating from one subsystem to another, thereby improving reliability. This may also allow a subsystem to be automatically shut down and restarted on fault detection.
* Immunity-aware programming can help engineers produce more reliable embedded systems code.<ref name=":1">{{Cite book|last=Short|first=Michael|title=2008 IEEE/ACS International Conference on Computer Systems and Applications |chapter=Development guidelines for dependable real-time embedded systems |date=March 2008|chapter-url=https://ieeexplore.ieee.org/document/4493674|pages=1032–1039|doi=10.1109/AICCSA.2008.4493674|isbn=978-1-4244-1967-8|s2cid=14163138|url=https://figshare.com/articles/conference_contribution/Development_Guidelines_for_Dependable_Real-Time_Embedded_Systems_/10083272 }}</ref><ref>{{Cite web|last=Motor Industry Software Reliability Association|title=MISRA C:2012 Third Edition, First Revision|url=https://www.misra.org.uk/product/misra-c2012-third-edition-first-revision/|access-date=2022-02-03|language=en-GB}}</ref> Guidelines and coding rules such as [[MISRA C|MISRA C/C++]] aim to assist developers produce reliable, portable firmware in a number of different ways: typically by advising or mandating against coding practices which may lead to run-time errors (memory leaks, invalid pointer uses), use of run-time checks and exception handling (range/sanity checks, divide-by-zero and buffer index validity checks, default cases in logic checks), loop bounding, production of human-readable, well commented and well structured code, and avoiding language ambiguities which may lead to compiler-induced inconsistencies or side-effects (expression evaluation ordering, recursion, certain types of macro). These rules can often be used in conjunction with code [[Static program analysis|static checkers]] or bounded [[model checking]] for functional verification purposes, and also assist in determination of code [[Worst-case execution time|timing properties]].<ref name=":1"/>

===High vs. low volume===
For high-volume systems such as [[mobile phone]]s, minimizing cost is usually the primary design consideration. Engineers typically select hardware that is just good enough to implement the necessary functions.

For low-volume or prototype embedded systems, general-purpose computers may be adapted by limiting the programs or by replacing the operating system with an RTOS.