Embedded software often fails in places that do not look architecture-related at first.
A firmware image is flashed but never reaches main(). An exception handler is never entered. A Linux program reports Exec format error. A driver gives a buffer to DMA and then reads stale data. Unaligned access works on one chip and becomes a hard fault on another. The same assembly startup code fails completely on a different profile.
In an RTOS project, task count can grow from two to a dozen quickly.
A common split looks natural:
This is not always wrong, but it often splits code by module name. Tasks actually affect scheduling, blocking, stacks, priorities, synchronization, and resource ownership. Bad task boundaries later look like concurrency bugs.
The first model is:
Read MoreWhen an RTOS device resets in the field, hits a random HardFault, jumps into invalid code, or corrupts queue data, engineers often suspect pointers, concurrency, peripherals, or power.
Those are valid suspects, but one common cause is simpler: a task stack is too small.
RTOS tasks usually do not have a large process address space or strong isolation like Linux processes. Each task owns a stack region whose size is often fixed at task creation. Make it too large and RAM is wasted. Make it too small and the failure may not happen immediately; the stack may silently overwrite nearby memory.
Read MoreA common Linux device-debugging problem looks like this: the driver code did not change, the kernel boots, but the device never probes. The log may only say probe failed, or the driver may never be entered at all.
The problem is not always in C code.
On many embedded Linux platforms, whether a driver can find a device and obtain register ranges, interrupts, clocks, power supplies, GPIOs, and DMA channels first depends on whether the board description is correct. On ARM, RISC-V, and many embedded platforms, that description is usually Device Tree.
Read MoreThe hardest field failures are often not “the device crashed,” but “the device crashed, rebooted, and left nothing useful behind.”
After reboot, everything may look normal. Services restart, the network reconnects, logs begin from the new boot. Users only know the device was offline. Engineers have to guess: application crash, kernel panic, watchdog reset, power loss, voltage dip, or an external MCU resetting the main processor?
The goal of crash evidence is not to save every log line. Useful evidence should be small enough, reliable enough, and specific enough to let the next boot identify the failure type, failure location, system state, and recovery path.
Read MoreIoT devices often need to save power. When the screen is off, the network is idle, or sensor sampling is infrequent, the system wants to enter a low-power state.
From the application point of view, sleep can look like “pause for a while and continue when an event arrives.” Inside the system, much more happens.
Device sleep is not just pausing the CPU. The system may stop CPU cores, lower frequencies, gate peripheral clocks, cut power domains, save register state, freeze user processes, run driver suspend callbacks, and leave only a small set of wake sources enabled.
Read MoreMany devices have a watchdog. The common explanation is simple: if the system freezes, the watchdog times out and reboots it.
That is not wrong, but it is too shallow.
A useful watchdog is not merely a timed reset mechanism. It asks a more specific question: are the critical paths that must keep making progress actually still making progress?
If the watchdog is fed from the wrong place, the business thread may be deadlocked while the system still feeds the watchdog on time forever. If the timeout is too short for real scheduling and I/O behavior, the system may reset even though it could have recovered normally.
Read MoreWhen comparing an RTOS and Linux, people often start with an intuitive difference: an RTOS is small, Linux is large.
That is true, but too coarse. What affects engineering choices and debugging is not binary size alone. It is the different problems they are designed to solve by default.
An RTOS is common in resource-constrained device-side systems with clear response paths and fixed control cycles. Linux is common when resources are richer and the system needs process isolation, network stacks, filesystems, complex drivers, and application ecosystems.
Read Moregcc-arm-none-eabi versions.Think of it as a “development environment installer” containing all necessary tools and libraries.
Read More