Debugging LEDs

Overview

Today’s 45-minute micro:bit STEM lesson focuses on debugging LED display programs. Students work in pairs to find and fix common errors using a structured debugging guide, connecting mistakes to clear reasoning and test results.

Learning intentions

• Students will be able to identify and describe common causes of incorrect micro:bit LED behavior.
• Students will use a step-by-step debugging process to locate faults in simple LED display code.
• Students will be able to verify fixes by re-running programs and interpreting the results.
• Students will explain their reasoning using clear, test-based statements.

Success criteria

• I can predict what my program should do before I run it.
• I can use the debugging guide to test small changes and narrow down the cause.
• I can identify at least one specific error (not just “it didn’t work”) and fix it.
• I can explain what I changed and why the change worked using evidence from the display.

Curriculum links

• The Number System: interpret and compute quotients of fractions using visual models and equations (a reasoning habit that supports checking “how much/which parts” change when students test small code edits).
• The Number System: understand opposite directions/values and use sign meaning in real-world contexts (used when students interpret coordinate-style thinking like left/right or above/below in LED layouts).
• The Number System: recognize reflections across axes in ordered pairs (mirrors debugging by checking “what stays the same” vs “what flips” after a change).
• The Number System: interpret inequality on number lines and absolute value as distance from zero (supports magnitude/distance thinking when students compare expected vs actual patterns).

Lesson structure (45 minutes)

1. 0–5 min · Hook (pattern prediction). Teacher displays two short LED examples (one correct, one with a visible error) and asks, “What do you expect the LEDs to do, and what went wrong in the incorrect one?” Students do a quick think-pair-share and write one sentence: “I expect ___ because ___.”

2. 5–12 min · Mini direct teach (debugging approach). Teacher introduces a simple “Debugging Loop” and models it once on the board: Predict → Run → Observe → Compare → Change one thing → Re-run. Students repeat the loop while the teacher points to common errors (wrong variable/value, off-by-one index, swapped rows/columns, missing or extra condition, inverted timing).

3. 12–14 min · Student setup and goals. Teacher assigns pairs, gives each pair the same target challenge: “Debug the LED display program so it matches the expected pattern.” Students open the provided starter code and confirm they can run it once (baseline).

4. 14–30 min · Pair debugging sprint (structured). Teacher circulates with a debugging checklist, asking guiding questions rather than giving fixes. Students use the Debugging Guide (below) to complete at least two test cycles where they change one detail at a time and record what happened.

5. 30–38 min · Mid-lesson check (teacher conference + quick share). Teacher calls on 3 pairs to share one error they found and how they tested it (e.g., “Our index was off by one, so we shifted by one step and the row aligned.”). Students listen for “evidence-based” explanations and add one useful tip to a shared class notes board.

6. 38–44 min · Fix-and-verify final run. Teacher prompts, “Before you run, state your predicted change; after you run, state whether it matched.” Students run the corrected program at least once and complete a short “Expected vs Actual” comparison.

7. 44–45 min · Exit ticket (quick accountability). Teacher collects exit tickets: each student answers two prompts. Students submit: (1) What was the most likely bug? (2) What single change fixed it (or what will you try next)?

Debugging Guide (handout or board)

• Step 1: Predict what the LEDs will show (use words like “top row,” “middle column,” “left-to-right”).
• Step 2: Run & Observe (watch for timing issues too; note what matches and what doesn’t).
• Step 3: Compare expected vs actual using one clear sentence.
• Step 4: Choose one suspect (index value, condition, row/column swap, timing delay, loop bounds, sign/direction choice like up vs down).
• Step 5: Change one thing and re-run.
• Step 6: Decide
• If it improved: keep that change and test the next smallest adjustment.
• If it got worse: undo and test the next suspect.

Resources

• micro:bit devices (or simulation if needed)
• laptops/tablets with the micro:bit editor installed
• starter “buggy” LED program files for each pair
• printed Debugging Guide (1 per student or per pair)
• Expected LED pattern reference sheet (a simple grid picture)
• student recording sheet: Baseline, Test 1, Test 2, Expected vs Actual, Fix description
• timer for sprint management
• optional: magnification or screen-sharing for teacher modeling

Assessment

• Formative during the sprint: teacher checks that pairs are following “change one thing” and recording observations.
• Formative conference prompt: “What did you predict, what did you observe, and what did the observation tell you?”
• Exit ticket (1 minute): identifies the specific bug and the evidence-based change (or next test).

Differentiation

• Support: provide sentence starters for explanations: “We predicted ___, but observed ___. This suggests the bug is ___. We changed ___.”
• Support: offer a “Common Errors” card with quick examples (off-by-one index, swapped coordinate, missing condition, delay too short/long).
• Extension: challenge one pair to improve the program to handle two input cases (e.g., two different patterns depending on a button press) using the same debugging loop.
• EAL/SEN: allow students to record evidence with quick sketches of the LED grid, not only sentences; also permit partner roles (Coder/Recorder) to reduce cognitive load.

Lesson pacing tip (for a 25-student room)

• Keep pairs to 2–3 students worth of devices (5–10 micro:bits is fine) by rotating stations: Code debug station, Run/Observe station, Recorder station.