5.1Cross-development environment

In embedded development, running a compiler directly on the target microcontroller board is not practical. Developers run the development environment on a host such as a PC, generate executable code for the target, place it according to the target's memory layout, and finally must directly observe whether the code behaves as written on the target hardware itself. This section builds an understanding of how the toolchain divides these roles, and the judgment needed to choose the right tool for real-hardware debugging.

5.1.1Cross compiler, linker, and locator

• A cross compiler runs on the development host (a PC, typically x86) but generates machine code for the target (an embedded board, e.g., ARM Cortex-M). It is needed because the host and target CPU architectures differ.
• A linker combines multiple compiled object files and libraries into a single executable file. A locator places the linked code and data at specific addresses on the target's actual memory map (Flash start address, RAM start address, etc.). In embedded development, the standard practice is to check the map file the locator produces to verify that code size and data placement fit within the target's memory capacity.

5.1.2Real-hardware debug tools (ICE / JTAG / SWD / emulators)

• An ICE (In-Circuit Emulator) substitutes dedicated hardware that emulates the target CPU, allowing real-time observation and control of internal registers and bus state—a highly capable real-hardware debugging device. It is expensive, but can trace internal states not visible on the real CPU.
• JTAG (Joint Test Action Group) is a standard originating from boundary scan, accessing the target CPU directly via dedicated pins to set breakpoints, read/write registers and memory, and program flash—the most widely used debug interface today. SWD (Serial Wire Debug), used on ARM-based microcontrollers, is an alternative interface with fewer pins (two) than JTAG, suited to small embedded devices where board space and connector count are at a premium.
• An emulator (in the broad sense) is an environment that simulates CPU and peripheral behavior in software without using actual target hardware. It is useful before real hardware is available, or in early-stage development where multiple design options must be compared quickly, but it has the limitation that it cannot fully reproduce actual clock precision, electrical behavior, or hardware-specific timing issues. Final performance and timing verification must still be done on real hardware (via ICE/JTAG/SWD).

Suppose a firmware developer working on a small sensor device built around an ARM Cortex-M finds that simulation on an emulator runs correctly, but flashing the real hardware causes sensor-value reads to fail at certain timings. From this symptom, they judge that the cause is likely hardware-specific electrical behavior or timing that the emulator cannot reproduce, and switch to direct observation on the real hardware. Because the board is extremely small and has no room for JTAG's bulkier connector, they connect the debugger via the low-pin-count SWD. Setting breakpoints via SWD and observing CPU registers and memory immediately before and after the sensor-read routine, they discover that immediately after communicating with the sensor, the CPU switches to a different interrupt handler, exceeding the communication's timing constraint (the next command must be sent within a fixed window). Had an expensive ICE been available, it could have traced internal CPU bus state in real time for even more detailed root-cause analysis, but in this case register observation via SWD alone was enough to pinpoint the cause, so procuring an ICE was judged unnecessary. As in this example, early-stage verification on an emulator and final verification on real hardware via ICE/JTAG/SWD play different roles, and whenever a symptom stems from timing or electrical behavior, the developer must return to observation on real hardware—this is the judgment expected of an embedded developer.

5.1.3Section summary

• The cross compiler runs on the host and generates code for the target; the linker/locator place it at the target's actual memory addresses
• JTAG is the standard multi-pin interface, SWD is a low-pin ARM-oriented option, and ICE is expensive but can observe even internal state
• An emulator is useful for early verification but cannot reproduce electrical behavior/timing—final verification must always be on real hardware