courses

HW 2: Bus Analysis and Debug Port Discovery

Covers: Weeks 3–4 Due: Friday of Week 4 — 23 October 2026, 23:59:59 Points: 100

Introduction

HW #1 got a signal off a board using the simplest possible interface. This assignment moves to the buses that carry the interesting data — I2C and SPI — and then to the interface that bypasses the firmware entirely, JTAG/SWD.

The through-line: each interface you add gives you a different kind of access. UART gives you what the firmware chose to say. I2C and SPI give you what the firmware says to its own peripherals, which it did not intend for you to read. JTAG gives you the silicon, regardless of what the firmware wants.

You will use your own Feather stack as a known-good reference for calibrating the tools, then apply the same techniques to the unknown target from HW #1.

Tasks

Task 1 — I2C capture and decode

20 points.

The OLED FeatherWing on your own stack is an I2C device, which makes it an ideal calibration target: you know what it is and you can compare your decode against the datasheet.

  1. Attach your logic analyzer to SDA and SCL. Capture the initialization sequence that runs when your board boots.
  2. Decode the capture and include the screenshot.
  3. From the decoded capture alone, report:
    1. The 7-bit device address, and how you distinguished the address from the R/W bit.
    2. Whether the device ACKed or NAKed, and where in the transaction you can see it.
    3. At least three command bytes sent during initialization, cross-referenced against the display controller’s datasheet.
  4. Explain in your own words why an I2C capture tells you what devices exist on a board, while a SPI capture on MOSI/MISO alone does not.

Task 2 — SPI flash identification, in situ

25 points.

  1. Locate the SPI flash on the unknown target. Justify your identification from position and package before you probe.

  2. Attach your logic analyzer to SCK, MOSI, MISO, and CS. Capture the first few milliseconds after power-on.

    ⚠️ Capturing CS is not optional. Without it your decoder cannot determine transaction boundaries, and on a multi-device bus it cannot tell you which device was being addressed.

  3. Find the JEDEC ID query (0x9F) in your capture. Decode the three-byte response and identify the manufacturer, memory type, and capacity — see the worked example in Week 3.
  4. State the flash part number and its total size in both MiB and Mbit. Link the datasheet.
  5. Identify at least two other SPI commands in the capture besides 0x9F, and explain what the bootloader was doing.

This task produces the information you need for HW #3. Get it right.

Task 3 — Bus behavior under contention

15 points.

A short written analysis, no bench work required beyond what you have already captured.

  1. Explain what would happen electrically if you connected a Bus Pirate in active SPI master mode to the flash bus while the SoC was running.
  2. Describe two methods for reading the flash in-circuit without the SoC interfering, and state a specific risk of each.
  3. Under what circumstances would you stop trying to read in-circuit and desolder the chip instead? Give a concrete decision criterion, not “when it is difficult.”

Task 4 — Debug port discovery

25 points.

  1. Survey the unknown target for candidate debug interfaces: unpopulated headers, test pads, via clusters. Photograph and document each candidate.
  2. Determine whether the target exposes JTAG, SWD, both, or neither. Document your method — standard-pinout guess, JTAGulator scan, or datasheet-plus-tracing.
  3. If you find a working port, capture and report the IDCODE. Decode it into manufacturer, part number, and revision, and state whether it agrees with your Task 1 chip identification from HW #1. Disagreement is an interesting finding, not a failure — investigate and report it.
  4. If you find no working port, document the search space you covered — which pin combinations you tried — and state what you would try next given more time. A well-documented negative result receives full credit; an undocumented one does not.
  5. Attempt to halt the core with a Black Magic Probe or equivalent. Report whether it succeeded. If it failed, report the error and your interpretation.

Task 5 — Lockdown analysis

15 points.

Written analysis, grounded in what you observed.

  1. Based on your Task 4 results, state whether you believe debug access is locked on this target, and give your evidence.
  2. Look up the SoC’s debug-protection mechanism in its datasheet or reference manual. Describe how it is meant to work — which fuse, register, or protection level controls it.
  3. Describe one documented technique for defeating that specific mechanism, with a citation. Do not attempt it; this task is analysis only. Fault injection against course hardware is available as a final project option.
  4. If debug is not locked, explain what an attacker with five minutes of physical access could do, and what it would cost the vendor to prevent it.

Submission

Commit hw2/hw2.md and supporting images to your repository before the deadline.

Carry forward the flash part number from Task 2 into your HW #3 notebook — you will need it, and having it recorded in two places is cheap insurance.

Grading

Item Points
Task 1 — I2C capture and decode 20
Task 2 — SPI flash identification 25
Task 3 — Bus behavior under contention 15
Task 4 — Debug port discovery 25
Task 5 — Lockdown analysis 15
Total 100

Notebook quality is assessed within each task rather than separately. An undocumented result is an incomplete result.

References

Related course pages: Schedule · Tools · HW #1 · HW #3 · Final Project

🛠️ Maintenance note: Task 4 depends on the unknown target actually exposing a debug port; verify this each term before assigning, and keep a known-unlocked backup board available so students who draw a locked target can still complete the halt step. JTAGulator firmware and Black Magic Probe firmware both change command syntax between major versions.