Error Injection and Corrupted-Frame Testing

Injecting an error is easy. Proving that something noticed is the work, and the two are often conflated: a suite that injects six fault kinds and passes has demonstrated that it can produce six waveforms, not that six failures are detectable.

This chapter drives each injected fault into a receiver and records what reports it. Two of the six raise no error status at all — and the reasons are different, instructive, and both correct behaviour.

1. The Six Faults, and What Each One Is For

The injector is the one built in Chapter 14.2: one enumerated selector, six kinds, each mapped to a requirement from Chapter 14.1 §2.

ERR_NONE is not filler. It is the control: without it, a suite in which everything reports an error looks identical to a suite that is working.

2. The Detection Matrix

Each fault driven into the receiver of Chapter 14.4, 8E1, one frame each, carrying 0xA5:

  fault            frames  data_ok  parity_err  framing_err
  --------------   ------  -------  ----------  -----------
  NONE                  1      yes           -            -
  PARITY                1      yes         YES            -
  STOP                  1      yes           -          YES
  SHORT_STOP            2      yes           -            -
  GLITCH                1      yes           -            -
  BREAK                 1      yes           -          YES

Three rows behave as a status-register-based test would expect. Two do not, and they are the interesting ones.

3. The Two That Raise No Error

ERR_SHORT_STOP — detected by counting, not by a flag

Look at the frames column: 2, where every other row is 1.

The fault truncates the stop bit to half a bit and then drives a new start. The receiver finishes its frame normally — correct data, legal stop, no error — and then sees a falling edge where idle should be, and begins framing a second character out of what follows.

  SHORT_STOP            2      yes           -            -

No status bit reports this, and none should: the first frame genuinely was well-formed. What is wrong is that one frame was sent and two were received, which is a property of the stream, not of any frame in it.

The detection is arithmetic: frames observed must equal frames driven. That is a scoreboard check (14.5) and it is the only thing in the environment that can see this fault.

ERR_GLITCH — not detected, and correctly so

  GLITCH                1      yes           -            -

One frame, correct data, no errors. The spike happened and changed nothing.

That is not a missed detection. It is Chapter 5.4's subject measured from outside: a receiver samples each bit once, at the centre, and a disturbance that does not cover the sampling instant is invisible by construction. Whether a glitch matters is entirely a question of where it sits.

4. Locating the Glitch Window

"A glitch matters if it covers the sampling instant" is a claim, and it is measurable. A 6%-wide spike was swept across a data bit in 5% steps, and the byte checked each time:

  glitch start (fraction of a bit) -> byte corrupted?
    0.00  ->      clean
    0.25  ->      clean
    0.35  ->      clean
    0.40  ->      clean
    0.45  ->  CORRUPTED
    0.50  ->      clean
    0.55  ->      clean
    0.75  ->      clean
    0.90  ->      clean
  corrupting window: 0.45 .. 0.45 of a bit

One position out of nineteen. A spike starting at 0.45 spans 0.45 to 0.51 and therefore covers the sample at 0.50; every other placement misses it.

5. What the Waveforms Look Like

6. Verification

Inject a control. ERR_NONE proves the environment is not reporting errors that were never injected. A suite where every frame raises something is indistinguishable from a broken checker.

Check the frame COUNT, not only the frame contents. ERR_SHORT_STOP produces a well-formed frame and a spurious extra one; nothing per-frame can see it.

Do not require corrupted frames to be discarded. Every row of the matrix delivers its byte, deliberately. A test asserting rejection fails a correct receiver.

Sweep a positional fault; never inject it at one offset. The glitch damages at 1 of 19 positions. A fixed-offset test passes on a receiver with no noise rejection whatever, 95% of the time.

Map each fault to the mechanism that detects it, and expect some to map to nothing. Two of six are undetectable by status bits, and both for good reasons. A detection matrix with a tick in every cell has usually been written by choosing faults the status register already covers.

7. Debugging

8. Understanding Check

9. Summary

Injecting a fault is not the same as proving it is detected, and the detection matrix is how the difference is made visible.

Six faults: three report a status bit, one reports only as a frame count, one reports nothing, and one is the control.

Every fault delivers its byte, which is the receiver's documented behaviour and would fail a test written to expect rejection.

ERR_SHORT_STOP is a property of the stream, not of a frame — one driven, two observed — so only a scoreboard can see it.

ERR_GLITCH damages at 1 of 19 swept positions, a window exactly as wide as the spike, because a single sample is a point. A fixed-offset glitch test passes 95% of the time on a receiver with no noise rejection at all.

A detection matrix with a tick in every cell is suspicious: it usually means the faults were chosen to match the status bits that already exist.

10. What Comes Next

Chapter 15.5 applies the same treatment to the stresses that are not single-frame events: deliberate baud error, reset asserted mid-traffic, and the FIFO boundaries — including the one that hid a real defect through an entire verification suite.

Browse the full path on the UART tutorials index. For the injector these faults come from, read back to Chapter 14.2.