Software testing in embedded — unit tests on host, HIL testing: Worked examples

This page is a drill hall. The parent note told you the ideas — host unit tests versus HIL testing. Here we walk through every kind of scenario those ideas produce, one worked example per "cell". Guess the answer first (that's the Forecast line), then check yourself against the numbered reasoning.

Before any numbers, let us pin down the small pieces of arithmetic and every symbol the examples reuse, so no notation appears un-earned.

Definition The toolbox — conversions used everywhere below

ADC → voltage. An ADC (Analog-to-Digital Converter) is a chip that measures a voltage and reports it as a whole number (a "count"). A 12-bit ADC has $2^{12} = 4096$ possible counts, numbered $0$ to $4095$ . It maps a voltage range $[0, V_{ref}]$ onto those counts linearly — evenly, like ruler marks. So: $V = \frac{count}{4095} \times V_{ref}, count = round (\frac{V}{V _{ref}} \times 4095)$ We divide by 4095, not 4096, because count $4095$ must map to the full reference voltage (the last mark on the ruler is the end of the ruler).

Duty cycle (two steps, always in this order). A PWM (Pulse-Width Modulation) signal is a square wave that is "on" for a fraction of each cycle. That fraction, as a percent, is the duty cycle. A timer counts up to a maximum called TOP and switches off at a value called CCR (Compare-Capture Register). We first compute the integer $CCR$ , then the duty: $CCR = round (\frac{count}{4095} \times TOP), duty (%) = \frac{CCR}{TOP} \times 100.$

That is the entire toolbox. Everything below is these lines plus careful case-splitting. Two pictures make them concrete:

Figure — Software testing in embedded — unit tests on host, HIL testing

The scenario matrix

Every testing question in this topic falls into one of these cells. The examples that follow are labelled with the cell they cover, and together they hit all of them.

Axis	Cell	What could go wrong / what it tests	Example
Signal sign	Positive input	mid-range mapping, rounding	Ex 2
Signal sign	Zero input	0 count → 0 V → 0% duty, off-by-one at bottom rail	Ex 1a
Signal sign	Saturated-high input	clipping / cap at the top rail	Ex 1
Degenerate input	`dt = 0`	divide-by-zero → +inf	Ex 3
Degenerate input	Empty buffer	length 0 → divide-by-zero in an average	Ex 3b
Limiting value	0% and 100% duty	rounding at both rails	Ex 1, Ex 1a
Where to test	Pure logic vs hardware timing	choosing host vs HIL	Ex 4
Real-time deadline	$T_{measured}$ vs $T_{deadline}$	ISR latency, missed deadline	Ex 5
Mock correctness	Mock returns wrong / stale value	false green test	Ex 6
Real-world word problem	Throttle → motor mapping end to end	full HIL loop	Ex 7
Coverage / strategy	80% host-coverage target	test-budget maths	Ex 8
Exam-style twist	"This test passes — why is it worthless?"	flaky/tautological tests	Ex 9

Every cell is covered. Let's go.

Forecast: guess the voltage (a bit under 3.3 V? exactly 3.3 V?) and the duty (99.9%? 100%?) before reading on.

Find the max count. 12-bit → counts $0 \dots 4095$ , so max count $= 4095$ . Why this step? The rail is where off-by-one bugs live; we must use $4095$ , not $4096$ .
Convert to voltage. $V = \frac{4095}{4095} \times 3.3 = 3.3 V$ . Why this step? Confirms the top count maps to exactly $V_{ref}$ — the ruler-end property.
CCR, then duty. $CCR = round (\frac{4095}{4095} \times 1000) = 1000$ , capped at $1000 = TOP$ , so $duty = \frac{1000}{1000} \times 100 = 100%$ . Why this step? Saturated input should give saturated output; a bug that produced $100.02%$ (CCR $= 1002$ ) would overflow the timer.

Verify: Voltage $3.3$ V is the reference itself ✓ (units: count/count × V = V). Duty $100%$ is the physical maximum; anything above is impossible, so the cap is doing its job ✓.

Forecast: is the voltage exactly 0 V or a tiny positive offset? Is the duty exactly 0%, or does rounding sneak in a stray count?

Find the min count. The bottom rail of a 12-bit ADC is count $= 0$ . Why this step? The zero end has its own off-by-one danger (a bug returning $1$ instead of $0$ would leak a tiny always-on PWM).
Convert to voltage. $V = \frac{0}{4095} \times 3.3 = 0 V$ . Why this step? Confirms the bottom count maps to exactly $0$ V — the ruler's start.
CCR, then duty. $CCR = round (\frac{0}{4095} \times 1000) = 0$ , so $duty = \frac{0}{1000} \times 100 = 0%$ . Why this step? Zero input must give a dead motor. If rounding produced CCR $= 1$ , the motor would creep — exactly the bug a host test at count $0$ catches.

Verify: $0/4095 = 0$ → $0$ V ✓; $0/1000 \times 100 = 0%$ ✓. Both rails (Ex 1 = 100%, Ex 1a = 0%) now bounded, so the linear map is pinned at both ends ✓.

Forecast: is the count exactly $2047$ , $2048$ , or $2047.5$ ? Is the CCR $500$ ? Is the duty exactly $50%$ ?

Voltage → count. $count = round (\frac{1.65}{3.3} \times 4095) = round (2047.5) = 2048$ . Why this step? $2047.5$ is not an integer — the ADC must round. Half-scale voltage does not give half-scale count exactly; this asymmetry (0…4095 is an even span, so it has no exact middle) is a classic surprise.
Count → CCR (the step the formula demands first). $CCR = round (\frac{2048}{4095} \times 1000) = round (500.122) = 500$ . Why this step? We must compute the integer CCR before the duty — the timer can only hold whole numbers, so the rounding here is real hardware behaviour, not a shortcut.
CCR → duty. $duty = \frac{500}{1000} \times 100 = 50.0%$ . Why this step? After CCR rounds to $500$ , the duty lands on an exact $50.0%$ — the integer rounding actually cancelled the half-count offset from step 1. That is only visible if you keep CCR as a separate step.

Verify: count $= 2048$ ✓; $round (2048/4095 \times 1000) = round (500.122) = 500$ ✓; $500/1000 \times 100 = 50.0%$ , inside a $\pm 2%$ tolerance ✓. Keeping the CCR step honours the stated formula and shows the two roundings interact.

Forecast: a crash? a NaN? a huge number? Which output field poisons the result?

Compute the derivative term literally. $\frac{e - e _{prev}}{d t} = \frac{3 - 1}{0} = \frac{2}{0}$ . Why this step? In C floating-point, $2.0/0.0$ is not a crash — it yields +inf. This is a silent poison, worse than a crash.
Propagate through the sum. Output $= K_{p} e + K_{i} \cdot integral + K_{d} \cdot (+ \infty) = 6 + 0 + \infty = + \infty$ . Why this step? Any finite term added to infinity stays infinity — the whole controller output becomes meaningless.
The host-test fix. A unit test on host can inject $d t = 0$ cheaply in microseconds and assert isfinite(output). On HIL you'd only see a motor slam to full power. Why this step? This is the whole reason degenerate inputs go in the host tier: fast, safe, repeatable.

Verify: IEEE-754 says $2/0 = + \infty$ and $finite + \infty = + \infty$ ; isfinite(+inf) is false ✓. So an assertion isfinite(pid_update(...)) correctly fails, catching the bug on host.

Forecast: does an empty buffer give $0$ , or something worse?

Substitute the degenerate size. $avg = \frac{0}{0}$ . Why this step? $\sum$ over zero terms is $0$ , and dividing by $n = 0$ gives $0/0$ — the worst float result, NaN (Not-a-Number), which is not even equal to itself.
Trace the poison. Any comparison with NaN is false, so a later if (avg > threshold) silently takes the wrong branch — no crash, no warning. Why this step? Shows the empty buffer is a distinct hazard from Example 3: dt=0 gave +inf, but 0/0 gives NaN, which behaves differently in comparisons.
The host-test fix. Inject an empty buffer on host and assert the function guards it (returns a defined default, e.g. $0$ , when $n = 0$ ) rather than dividing. Why this step? Empty-collection edge cases are invisible on HIL until real startup — cheap to force on host.

Verify: $0/0$ is NaN; NaN == NaN is false (the defining property) ✓. A guarded implementation returning $0$ when $n = 0$ makes the test pass; the naive one produces NaN and fails ✓.

Forecast: which two are pure maths, which two need real silicon?

(a) CRC calculator → host. Why? Pure computation on bytes — same result on x86 as on the MCU. Mock nothing.
(b) UART ISR latency → HIL. Why? Latency is real time; host tests mock the clock, so they cannot measure microseconds of actual response. Needs a logic analyzer on the response pin.
(c) Kalman update → host. Why? Linear algebra with no I/O. Route sensor reads through the HAL and feed mock data.
(d) GPIO rises to 3.0 V → HIL. Why? Voltage level is an electrical property; only real hardware and a scope can confirm it.

Verify: The rule is "does the answer change with real timing or real voltage?" — (b) and (d) yes → HIL; (a) and (c) no → host. Two/two split matches the parent's "logic on host, physics on hardware" principle ✓.

Forecast: pass or fail? margin in µs and as a percent?

Compare worst case to deadline. $T_{measured} = 73 μ s < 100 μ s = T_{deadline}$ → pass. Why this step? Real-time correctness is decided by the worst case, never the average — a single missed deadline is a failure.
Compute absolute margin. $100 - 73 = 27 μ s$ . Why this step? Margin tells you how much future code (an added RTOS context switch, a slow I²C read) you can afford before the deadline breaks.
Compute relative margin. $\frac{27}{100} \times 100 = 27%$ . Why this step? Teams often require ≥ 20% headroom; $27%$ clears it.

Verify: $73 < 100$ ✓; margin $27 μ s$ , i.e. $27%$ of the deadline ✓ (see the timeline figure). Because we measured the max of 5000 runs (not the mean), the pass verdict is robust to jitter.

Forecast: green or red? and is a green here good news?

Compute what the mock actually returns. Buggy mock → count $= 0$ , so duty $= \frac{0}{4095} \times 100 = 0%$ . Why this step? We must trace the value the mock feeds the logic, not the value the test intended to inject.
Evaluate the assertion. The test asserts duty == 0, and duty is $0$ → the assertion passes. Why this step? A passing assertion is worthless if it passes for the wrong reason — the input never reached the logic.
Design a self-checking mock. Add a read-back assertion: after set_adc(1, 3000), assert hal_adc_read(1) == 3000. This catches the stale mock before trusting any duty value. Why this step? Tests must verify their own plumbing; otherwise every "green" is suspect.

Verify: With the correct mock, count $3000$ gives duty $\frac{3000}{4095} \times 100 \approx 73.26%$ , which is nowhere near $0$ . So the read-back check hal_adc_read(1) == 3000 would fail on the buggy mock, exposing it ✓.

Forecast: how far off from 50% is 49.8%, and does it clear ±2%?

Confirm the intended input. $1.65$ V is $\frac{1.65}{3.3} = 50%$ of full scale → the throttle is genuinely at half. Why this step? Establishes the "expected" number the assertion compares against.
Compute the error. $∣49.8 - 50.0∣ = 0.2%$ . Why this step? The spec is an absolute-percent tolerance, so we subtract directly.
Compare to tolerance. $0.2 < 2.0$ → pass. Why this step? The $0.2%$ gap is real hardware reality — ADC noise, DAC settling, integer rounding — and it lives well inside budget.

Verify: $∣49.8 - 50∣ = 0.2$ , and $0.2 < 2$ ✓. Sanity: the sub-1% error is consistent with the integer-rounding of Ex 2, so the number is physically believable, not too-good-to-be-true ✓.

Forecast: which denominator matters — all 10 000 lines, or just the testable logic?

Identify the testable population. Vendor drivers are assumed tested, so the meaningful denominator is logic + HAL glue $= 6500 + 500 = 7000$ lines. Why this step? Counting untestable vendor code in the denominator would unfairly punish the score and hide real gaps.
Logic-focused coverage. $\frac{6000}{6500} \times 100 \approx 92.3%$ of custom logic. Why this step? This is the number the parent's formula really cares about — bugs hide in your logic.
Whole-image coverage. $\frac{6000}{10000} \times 100 = 60%$ . Why this step? Shows how a naive denominator makes a good test suite look bad; always state which denominator you used.

Verify: $6000/6500 = 0.9231$ → $92.3% \geq 80%$ ✓ (logic target met). $6000/10000 = 0.60$ → $60%$ , which would fail a naive whole-image target — proving denominator choice matters ✓.

Forecast: what is the smallest and largest a duty CCR can ever be?

Bound the quantity being asserted. A PWM CCR is always a non-negative integer: $CCR \geq 0$ by construction. Why this step? The assertion >= 0 is a tautology — it is true for every possible input, including a totally broken compute_pwm that returns $0$ .
Show it can't distinguish bug from correct. Max ADC $4095$ should give CCR $= 1000$ (from Ex 1). But a bug returning CCR $= 0$ also satisfies >= 0, so the test is green while the motor is dead. Why this step? A good assertion must be falsifiable — it must fail for at least one wrong output.
Fix it. Replace with the expected value: assert(hal_pwm_get(1) == 1000);. Why this step? Now a bug returning $0$ fails the test, which is the entire point.

Verify: 0 >= 0 is true, so a broken CCR of $0$ passes the weak assertion ✓ (it's worthless). The corrected == 1000 gives 0 == 1000 → false, correctly failing on the bug ✓.

Recall Quick self-check

Zero ADC count on a 3.3 V, TOP=1000 system gives what voltage and duty? ::: $0$ V and $0%$ — both bottom rails pinned exactly. Half-scale voltage (1.65 V on a 3.3 V, 12-bit ADC) gives which count, CCR (TOP=1000), and duty? ::: count $2048$ , then CCR $round (500.122) = 500$ , then duty $50.0%$ . Why does dt = 0 in the PID give +inf but an empty buffer average gives NaN? ::: $2/0 = + \infty$ (nonzero over zero), but $0/0$ is indeterminate → NaN, which is not even equal to itself. A worst-case ISR latency of 73 µs against a 100 µs deadline leaves what margin? ::: 27 µs, i.e. 27% headroom. Why is assert(duty >= 0) worthless? ::: A duty is non-negative by construction, so the assertion is a tautology — it can never fail, even on a broken output.