LA1010 / KINGSTVIS / UNO R4 WiFi / STM32F411RE
Code   Notes  
No matching chapters. Clear the search to return to the full book.
An illustrated laboratory book · 10 sections / 100 chapters

The Ultimate Guide
to the Kingst LA1010
Logic Analyzer

Stop guessing what your circuit is saying.
Generate it. Capture it. Decode it. Explain it.

KingstVIS walkthroughsArduino UNO R4 WiFiSTM32F411RE · CMSIS CInteractive SVG labs
Measurement concept mapGive your circuit a timelineGENERATEPROBECAPTUREEXPLAIN
Original teaching illustration. All waveform examples in the guide are illustrative unless explicitly described as your own capture.

How to use this book

Read a short chapter, predict what will happen, perform its bench steps, and explain the result before revealing the checkpoint answer. Each section contains exactly ten chapters. The first labs need only one board, the analyzer and a few wires; resistors and a button support later experiments.

This is an original practical course built from manufacturer documentation. It is not a condensed reproduction of a commercial textbook. Diagrams use a breadboard-lab visual language with simplified board shapes; they are not photographs or exact connector-position drawings.

Software baseline: researched KingstVIS v3.6.6; control paths checked against Kingst’s available v3.5 manual. Where interfaces differ, follow the control’s function and your installed version’s labels. No KingstVIS hardware session was available during authoring.

Board baseline: UNO R4 WiFi main-sketch labs use the RA4M1; the ESP32-S3 is its companion. STM32 labs assume NUCLEO-F411RE, not an arbitrary F411 board. Examples are source-reviewed teaching programs; no target-toolchain build or physical-board validation is claimed.

First eveningChapters 1–10, 11–20, then 21–25. Make and measure your first known pulse.
Build fluencyFinish the board foundation, then UART, I²C and SPI. Decode one byte manually in every protocol.
Work independentlyUse Sections 8–10 to design captures, measure firmware latency and debug control systems.

The guide works as a single HTML file without external libraries. Open it in a modern browser for interactive diagrams, search, downloads and saved reading progress. Print/PDF opens answers and source code. Allow roughly 20–40 focused bench sessions; this is a suggested learning pace, not a fixed course schedule.

Section 01 · Chapters 001–010

Learn to see time

The instrument and the evidence

A logic analyzer is a recorder for electrical decisions. Before trusting the colored labels, learn what the instrument actually observes—and what it throws away.

001 The question a multimeter cannot answer 002 A threshold turns voltage into a bit 003 Meet the LA1010—not the LA1016 004 Collect your first bench kit 005 Ground is the other half of every measurement 006 Sample rate is a ruler for time 007 Aliasing: a convincing trace can be false 008 Depth buys duration 009 Choose the right tool for the next question 010 Learn the capture contract
Chapter 001

The question a multimeter cannot answer

Your LED flickers. A sensor sometimes returns nonsense. A motor controller ignores every tenth command. A multimeter can tell you that a supply exists, but it usually cannot tell you which wire changed first. Your useful question is now about events in time.

A logic analyzer records several digital signals against one time axis. Each channel is one observation point, not one complete peripheral. A UART transmitter needs one channel; a full SPI conversation commonly needs four. You can compare the moment firmware starts a job with the first outgoing bit and the final response.

Begin with a hypothesis: “The request went out, but no response followed.” Your capture should contain both sides and enough time after the request. Merely collecting colorful waveforms is not a debugging method. For every lab in this guide, predict the trace before you press Start.

Measurement concept mapGive your circuit a timelineGENERATEPROBECAPTUREEXPLAIN
Original teaching illustration. All waveform examples in the guide are illustrative unless explicitly described as your own capture.

At the bench · do this next

  1. Write one question about a project you want to debug.
  2. Identify the two events that would answer it.
  3. List the wires carrying those events; include ground separately.

Pause & predict

A sensor gives zero. Does a zero-valued decoded byte prove the sensor is healthy?
Reveal the reasoning

No. It shows a particular bit pattern at the observed point. The wrong register, missing initialization, an electrically faulty line, or a real zero measurement may all produce that result.

Reference trail: K1K2 · Expected waveforms are teaching predictions, not measured records.
Chapter 002

A threshold turns voltage into a bit

The analyzer compares each input with a threshold. Above it becomes a displayed 1; below it becomes 0. That clean rectangular trace is a decision history, not a drawing of the actual voltage. A rounded rising edge, overshoot, and a perfect square edge can produce the same digital trace.

For these clean bench signals, use a starting threshold of 1.5 V on 3.3 V logic and 2.5 V on the UNO’s 5 V header signals. These are lab choices, not universal receiver specifications. Check the actual transmitter and receiver limits when investigating a marginal interface. LA1010 uses a common threshold setting for its inputs; mixed-voltage captures need a value valid for every observed signal.

Changing the threshold does not change the circuit voltage. Nor does it make a 5 V output safe for a 3.3 V microcontroller. It changes only the analyzer’s classification. If a suspicious pulse changes dramatically with threshold, an oscilloscope should examine the physical waveform.

Threshold comparisonVoltage becomes a decisionthreshold 1.5 VvoltagetimeAbove → HIGHBelow → LOW
The analyzer renders a digital decision, not this analog voltage curve.

At the bench · do this next

  1. Locate the threshold control in the interface map in Chapter 13.
  2. Predict the classification of 0 V and 3.3 V at 1.5 V.
  3. Try the sampling explorer later with a pulse near the sampling boundaries.

Pause & predict

Can the analyzer distinguish a 3.3 V HIGH from a 5 V HIGH at a 1.5 V threshold?
Reveal the reasoning

Both are displayed as HIGH. It has discarded their amplitude difference.

Reference trail: K1K2 · Expected waveforms are teaching predictions, not measured records.
Chapter 003

Meet the LA1010—not the LA1016

Similar model numbers conceal different acquisition architectures. The LA1010 has 16 input channels, but its top rate depends on how many you enable. Kingst specifies 100 MS/s for up to 3 channels, 50 MS/s for up to 6, 32 MS/s for up to 9, and 16 MS/s for up to 16. Enable only the channels needed for the question.

The LA1010 streams to the computer; it has no onboard acquisition memory. The advertised maximum compressed depth of 10 GSa is conditional, not a guaranteed physical RAM capacity. Rapid activity on many channels consumes more resources than long quiet intervals. A slow USB path or insufficient host resources can matter.

Kingst lists a 20 MHz maximum digital-signal frequency and a 20 ns minimum pulse width. Those specifications do not promise that every 20 ns pulse will be usefully characterized at every channel count. At 16 MS/s, samples are 62.5 ns apart. Always evaluate the setting actually selected, not the largest number printed on the case. See sources K1–K2.

LA1010 channel-dependent maximum sample rateMore channels → lower maximum rateUp to 3 CH100 MS/sUp to 6 CH50 MS/sUp to 9 CH32 MS/sUp to 16 CH16 MS/s
Manufacturer model-specific limits. The limit follows enabled acquisition channels, not merely visible traces.

At the bench · do this next

  1. Read the model name on the case and in KingstVIS.
  2. Enable CH0–CH2 and inspect available rates.
  3. Enable CH0–CH3 and check the reduction in maximum rate.

Pause & predict

Can you capture four-wire SPI at 100 MS/s on this model?
Reveal the reasoning

No. Four enabled channels put you in the up-to-six-channel tier, whose maximum is 50 MS/s.

Reference trail: K1K2 · Expected waveforms are teaching predictions, not measured records.
Chapter 004

Collect your first bench kit

The essential kit is intentionally small: LA1010 and its USB data cable, its labeled probe harness, one development board with its own data cable, several short jumpers, and a way to identify ground. A multimeter makes continuity and supply checks much easier. An optional breadboard, pushbutton, two 4.7 kΩ resistors and one 1 kΩ resistor support the later labs.

You do not need a sensor for your first UART, I²C or SPI capture. The board can generate known UART bytes; an address-only I²C transaction deliberately ends in NACK without a target; SPI loopback returns the controller’s own bits. Removing unknown peripherals makes the first experiments easier to interpret.

A probe is a connection to an input, not a source of board power. Never assume a red wire is a power lead or a black wire is necessarily the correct connector position. Harness colors vary. Trace labels from the device to the hook and build your own channel map. Keep PWM output leads separate until their dedicated lesson.

Measurement concept mapA small bench, a complete experimentBOARDPROBESGROUNDCOMPUTER
Original teaching illustration. All waveform examples in the guide are illustrative unless explicitly described as your own capture.

At the bench · do this next

  1. Lay out only one target board for the first session.
  2. Label CH0, CH1 and GND at the probe ends.
  3. Find a genuine GND pin on the board pinout before connecting anything.

Pause & predict

Must every unused input be attached to ground?
Reveal the reasoning

No. Disable unused channels for acquisition and keep loose hooks away from live connections. Floating inputs can show meaningless activity.

Reference trail: K1K2 · Expected waveforms are teaching predictions, not measured records.
Chapter 005

Ground is the other half of every measurement

A voltage is a difference between two points. Your CH0 reading means voltage at CH0 relative to the analyzer’s ground. With no ground reference, a waveform can be missing, unstable, or apparently plausible for accidental reasons.

The LA1010 ground is connected to USB ground and thus to the computer’s ground system. It is not an isolated differential probe. In this course, measure only low-voltage, USB-powered bench logic with a known common ground. The manufacturer’s wide input-voltage range is not an isolation rating, a mains safety category, or permission to probe a motor switching node.

Power the target off before arranging leads. Connect analyzer GND to target GND, then the signal probes. Check for adjacent-pin shorts before powering up. More than one short ground return can improve fast multi-channel captures, but every ground lead still goes to the same electrical ground network—not different supply nodes. Never attach ground to CAN-L, a motor terminal, or a high-side switch node.

LOW-VOLTAGE TARGET probe mapLOW-VOLTAGE TARGETSignal and its referenceKINGST LA1010INPUTS · passive probesLogic signalCH0Circuit GNDGNDUSB links analyzer ground to the computer. Never use a switching node as ground.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
Logic signalCH0
Circuit GNDGND

At the bench · do this next

  1. Power down the target.
  2. Connect labeled analyzer GND to a board GND header.
  3. Connect CH0 to the named signal pin, inspect spacing, then power the target.

Pause & predict

Why is connecting ground to the “low side” of a differential bus wrong?
Reveal the reasoning

A bus conductor is not necessarily ground. The USB-ground connection can force that conductor to ground, corrupt the bus, or damage hardware.

Reference trail: K1K2 · Expected waveforms are teaching predictions, not measured records.
Chapter 006

Sample rate is a ruler for time

At 1 MS/s the analyzer makes one decision per microsecond. At 10 MS/s it decides every 100 ns. At 100 MS/s it decides every 10 ns. The sample interval is Ts = 1/Fs. More closely spaced samples give finer timing resolution, within the input hardware’s limits.

A useful starting point is at least ten samples per clock or bit period for ordinary decoding. This is a practical starting rule, not a proof of capture quality. Narrow pulses require planning by pulse width, not just repetition rate: a 1 kHz signal with a 100 ns pulse is a fast-pulse measurement.

An edge that occurs between samples is located only within a sampling interval. Two independent edge measurements introduce interval uncertainty; a conservative simple budget is about two sample intervals for a measured width, before clock accuracy and analog threshold effects. Displaying many decimal places does not create more information.

Sampling explorer

A narrow 0.2 µs pulse repeats every 1 µs. Move the sample grid; see what survives.

Ideal threshold/sample model; excludes LA1010 analog bandwidth, pulse-width limits and clock error.

At the bench · do this next

  1. Calculate Ts at 16 MS/s: 62.5 ns.
  2. For 1 MHz SPI, start with 10 MS/s or a higher offered rate.
  3. For a 250 µs pulse at 1 MS/s, count roughly 250 samples across the HIGH.

Pause & predict

Is 2 MS/s a comfortable rate for detailed 1 MHz SPI inspection?
Reveal the reasoning

No. Two samples per clock period give little timing margin and poor edge placement. Use a substantially higher rate.

Reference trail: K1K2 · Expected waveforms are teaching predictions, not measured records.
Chapter 007

Aliasing: a convincing trace can be false

Imagine looking at a spinning wheel through a strobe. It can appear slow, stationary, or backwards. Sampling a digital signal has a related problem: transitions between sample instants can disappear. A narrow pulse entirely between two samples leaves no HIGH sample at all.

A decoder cannot reconstruct missing edges from confidence or clever formatting. If the capture never recorded an event, changing the UART baud setting or zoom level cannot restore it. A clean-looking decode can still be based on inadequate data, particularly for repetitive patterns.

When a trace surprises you, repeat the measurement at a higher sample rate, with fewer enabled channels and shorter probes. Keep the source program unchanged so that you are testing the measurement, not changing both variables. In the interactive explorer, move the sample phase as well as the rate. The same real pulse can produce different sampled evidence depending on alignment.

Sampling explorer

A narrow 0.2 µs pulse repeats every 1 µs. Move the sample grid; see what survives.

Ideal threshold/sample model; excludes LA1010 analog bandwidth, pulse-width limits and clock error.

At the bench · do this next

  1. Use the sampling explorer with a pulse shorter than Ts.
  2. Shift the sampling phase and observe whether the pulse vanishes.
  3. Increase Fs until multiple samples fall inside the pulse.

Pause & predict

If a pulse is absent from one capture, has the circuit proved that it never occurred?
Reveal the reasoning

No. It may be outside the recorded interval, below the threshold, shorter than the instrument can resolve, or between samples.

Reference trail: K1K2 · Expected waveforms are teaching predictions, not measured records.
Chapter 008

Depth buys duration

Sample depth is the number of time positions requested in a record. The basic relationship is duration = depth / sample rate. A request for 1 MSa at 10 MS/s corresponds to 0.1 s. If you increase the rate tenfold without changing depth, the time window becomes ten times shorter.

Plan around the question. For the shape of one UART byte, a millisecond may suffice. For the delay between a command and a response, you might need seconds. A higher rate that cuts off the response is worse than a moderate rate that captures the entire causal sequence.

LA1010 streaming and compression make the achievable record dependent on the host and activity. The displayed requested duration is a plan; inspect the actual start and end of the finished capture. Don’t infer a ten-second silent interval if acquisition stopped after two seconds. The calculator in Chapter 73 provides a rate/depth check without pretending to predict compression or USB performance.

LA1010 capture planner

Planning arithmetic only. Rates must also be available in your installed KingstVIS. Compression and achievable host duration are not predicted.

At the bench · do this next

  1. Choose a 100 ms target window.
  2. At 10 MS/s request at least 1 MSa, or the next supported depth.
  3. After acquisition, inspect the actual time range and acquisition status.

Pause & predict

What duration does 2 MSa provide at 50 MS/s?
Reveal the reasoning

0.04 s, or 40 ms, before any acquisition limits shorten the result.

Reference trail: K1K2 · Expected waveforms are teaching predictions, not measured records.
Chapter 009

Choose the right tool for the next question

Use a multimeter for DC supply and continuity checks. Use the logic analyzer for bit sequences, timing relationships and many simultaneous logic channels. Use an oscilloscope when voltage shape matters: ringing, slow rise time, overshoot, supply dips and noise margins.

The same failure may need all three. Suppose SPI data is occasionally wrong. The analyzer locates the transaction and identifies which bits differ. The oscilloscope then inspects the clock at the receiver. The multimeter checks whether the target’s supply is actually the expected rail.

A debugger also sees a different world. It can inspect registers and memory, but halting a processor changes timing and may stop some peripherals while others continue. A free-running capture observes the external consequence of the code. Read a register to ask what you configured; record a pin to ask what physically happened. Agreement between the two is strong evidence; disagreement tells you where to investigate.

Measurement concept mapChoose the question, then the instrumentDC VOLTAGEDIGITAL TIMEANALOG SHAPESTATE
Original teaching illustration. All waveform examples in the guide are illustrative unless explicitly described as your own capture.

At the bench · do this next

  1. Write “voltage”, “timing”, or “internal state” beside three bugs.
  2. Choose the first instrument for each.
  3. For a marginal HIGH level, plan an analog measurement.

Pause & predict

Can a rectangular analyzer trace certify good signal integrity?
Reveal the reasoning

No. Its threshold comparison hides much of the analog behavior.

Reference trail: K1K2 · Expected waveforms are teaching predictions, not measured records.
Chapter 010

Learn the capture contract

Every useful saved trace needs a small contract: what hardware, what firmware, which wires, what settings, what expectation, and what observation. Without that context, a week-old capture becomes an attractive mystery.

Use this notebook entry: board and revision; source filename or commit; signal-to-channel map; voltage domain and threshold; sample rate and requested depth; trigger and pretrigger position; filter state; decoder parameters; actual captured duration. Then add one sentence comparing result with prediction.

This guide progresses through controlled sources before real peripherals. Finish a section by explaining the trace in your own words, not just by reproducing a screenshot. Keep a known-good baseline before each deliberate fault. Mark chapters complete using the checkboxes; progress stays in your browser where local storage is available. Export your notes periodically because browser storage is not an archival format.

At the bench · do this next

  1. Create a folder named LA1010-labs.
  2. Write the capture contract in a text file.
  3. Set a first goal: measure a known pulse and explain its width.

Pause & predict

Which matters more in a bug report: the screenshot or its settings?
Reveal the reasoning

Both help, but the raw capture and settings are essential for independent re-analysis. A screenshot alone hides much of the evidence.

Reference trail: K1K2 · Expected waveforms are teaching predictions, not measured records.
Section 02 · Chapters 011–020

KingstVIS, one action at a time

Install → connect → capture → save

Use these chapters beside the application. The control names follow Kingst’s published v3.5 manual; the researched current release is v3.6.6. Drawn interface maps are explanatory, not screenshots of a live session.

011 Install the official software 012 Practice without the instrument 013 Read the five regions of the screen 014 Connect and prove the connection 015 Enable, label and arrange your channels 016 Set rate and depth deliberately 017 Your first capture: remove the trigger 018 Zoom, pan and place the timing markers 019 Add a decoder after understanding the wires 020 Save evidence you can reopen
Chapter 011

Install the official software

Download KingstVIS from Kingst’s own download page, source K3. At the research date it lists v3.6.6 for Windows, macOS and Linux; the published packages are x86 variants. Check the listing for your computer architecture and operating system rather than assuming a native ARM build exists.

On Windows, close other analyzer applications, run the official installer and allow its bundled device driver to install. Kingst’s manual places driver installation near the end. Connect the analyzer after installation. On macOS use the supplied package and the operating system’s normal application-opening process. On Linux read the package’s included installation and USB-permission instructions; don’t invent a universal udev rule from a different analyzer.

Record your installed version using the application’s About information. Keep it with your first capture. Kingst’s release notes show that decoding and filtering behavior can change between releases, so version information can explain why two people see different results from the same data.

At the bench · do this next

  1. Open source K3 and select the package for your OS/architecture.
  2. Install using the package instructions, including the Windows driver where applicable.
  3. Launch KingstVIS and record its version before connecting a target.

Pause & predict

Does successful application launch prove that the USB driver is working?
Reveal the reasoning

No. Demo mode can run without hardware. Device connection is a separate check.

Reference trail: K2K3K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 012

Practice without the instrument

KingstVIS includes demo operation. This is useful for learning zooming, decoder configuration and measurements before attaching any wires. Choose a simulated model from the device control and capture a demo signal. Kingst’s manual describes adding a protocol analyzer, then acquiring corresponding demonstration data.

Keep a conspicuous “DEMO” note in your notebook. Selecting a model in software does not prove that a matching physical device is connected. Before every real lab, check the connection status and deliberately change a real board output to verify that the displayed signal follows it.

For your first demo, add SPI through the Analyzers area, accept its demonstration channel assignment and acquire. Zoom until individual clocks are visible. Count eight clocks beneath a byte annotation. This teaches the most important decoder habit: the annotation is a claim about the waveform, and you can check that claim by counting.

KingstVIS functional interface map① LA1010 / settings Depth Rate ▶ Single ↻ Repeat ■ Stop ☰② ThresholdCH0 · SDACH1 · SCLTrigger controls③ Time ruler & waveform④ MeasurementsA1 · A2 · Δt⑤ Analyzers +Decoded ResultsUART · I²C · SPIStatus: confirm a physical device is connected before treating data as real.
Original schematic interface map based on Kingst’s published manual; not an exact v3.6.6 screenshot. Read the nearby chapter for control paths.

At the bench · do this next

  1. Disconnect the target and enter demo operation.
  2. Add an SPI analyzer, then start a demo acquisition.
  3. Zoom to one byte and count its clocks; save nothing as hardware evidence.

Pause & predict

You selected “LA1010” from a model list. Is that sufficient proof of a live connection?
Reveal the reasoning

No. Confirm the device-connected status and observe an intentional change at a physically probed signal.

Reference trail: K2K3K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 013

Read the five regions of the screen

The top toolbar handles acquisition and its overall settings. The left side identifies channels and their trigger conditions. The central area is your waveform and time ruler. On the right, measurement tools and protocol analyzers interpret the record. The status area tells you whether the device is connected and what acquisition is doing.

Learn these functions before memorizing icon positions. Window sizes, localization and software releases can move controls. In the published manual, threshold selection is near the top left; device settings sit beside the model; the main menu is at the top right. Treat the accompanying drawing as a map of responsibilities, not a pixel-perfect replacement for your application.

A productive reading order is: connection status, channel labels, time scale, raw edges, measurements, decoded values. Beginners often start with the decoded bytes, which makes it easier to miss a wrong channel assignment or a badly undersampled clock.

KingstVIS functional interface map① LA1010 / settings Depth Rate ▶ Single ↻ Repeat ■ Stop ☰② ThresholdCH0 · SDACH1 · SCLTrigger controls③ Time ruler & waveform④ MeasurementsA1 · A2 · Δt⑤ Analyzers +Decoded ResultsUART · I²C · SPIStatus: confirm a physical device is connected before treating data as real.
Original schematic interface map based on Kingst’s published manual; not an exact v3.6.6 screenshot. Read the nearby chapter for control paths.

At the bench · do this next

  1. Locate the model/connection indicator.
  2. Find rate, depth, threshold and Start/Stop controls.
  3. Find Analyzers, measurements, and the main save/export menu.

Pause & predict

Where should you look first when there is no waveform?
Reveal the reasoning

At device status and acquisition state, then wiring and channel selection—not immediately at decoder settings.

Reference trail: K2K3K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 014

Connect and prove the connection

Leave the target unpowered while attaching the harness. Plug the LA1010 into a reliable computer USB port with a known data cable. In KingstVIS, confirm the device model and connected status. If Windows lists an unknown device, inspect Device Manager and the official driver installation before troubleshooting your circuit.

Next connect ground and a single signal from a running practice sketch. Chapter 22 supplies the first source. A controlled HIGH/LOW change is better than touching a floating probe: a floating lead can pick up noise that looks like success.

If connection is intermittent, simplify the USB path, try a known-good cable, close other software using the device, and reduce the initial capture burden. Don’t interpret a transport failure as a board timing fault. Conversely, a perfectly connected analyzer will still show a flat trace when the target is unpowered or the selected pin is wrong.

At the bench · do this next

  1. Connect LA1010 alone and verify its status.
  2. Connect GND and the first target signal with target power off.
  3. Power the programmed board; acquire with no trigger and a modest rate.

Pause & predict

The analyzer connects, but CH0 stays LOW. What are three next checks?
Reveal the reasoning

Check target power, probe-to-pin mapping, and whether the loaded firmware actually drives that pin.

Reference trail: K2K3K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 015

Enable, label and arrange your channels

Open device settings beside the model and find Channel Select or Channel Enable Settings. Turn on only what the experiment uses. Channel count affects the LA1010’s available sample rate, so this is an acquisition decision rather than merely a tidier screen.

Click a channel name to give it a functional label such as UART_TX, I2C_SDA or TASK_ACTIVE. Keep the physical channel number in your notes. A decoder may also supply signal labels, but the underlying CH number remains the connection you must verify.

Use distinct colors and enough trace height to see edges. If needed, reset channel settings and rebuild the configuration. A leftover trigger on a hidden or irrelevant channel can cause endless waiting. Before the first acquisition, explicitly clear previous trigger conditions and turn off glitch filters. Store a clean setup once the baseline works.

At the bench · do this next

  1. Enable CH0 and CH1 only for the first two-wire experiment.
  2. Rename them PULSE_D7 and FRAME_D8.
  3. Remove all triggers and filters; select the sample rate after setting channel count.

Pause & predict

Why can hiding a trace and disabling a channel mean different things?
Reveal the reasoning

A hidden trace may still participate in acquisition. Use the actual enable/selection setting and verify the resulting rate options.

Reference trail: K2K3K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 016

Set rate and depth deliberately

For the initial UNO pulse source, start at 1 MS/s with a requested duration around 100 ms. If the depth menu offers a different convenient combination, use duration = depth/rate and choose the next longer window. The purpose is to see several frames and still resolve a 250 µs pulse.

Use the sampling-rate control and then the depth control in the top toolbar. Read the duration KingstVIS calculates. A unit mistake is costly: MSa is a count of samples, while MS/s is a rate. “100 M” beside different controls can mean very different things.

Once a baseline appears, repeat at 10 MS/s while keeping the time window roughly unchanged by increasing depth. The displayed edge positions should agree within the coarser capture’s resolution and source timing variation. If the protocol changes radically with sample rate, revisit measurement quality before blaming the code.

At the bench · do this next

  1. Set 1 MS/s, then choose depth for at least 100 ms.
  2. Read back the displayed duration before Start.
  3. Repeat at a higher rate and compare a single pulse width.

Pause & predict

Why not always select maximum rate and maximum depth?
Reveal the reasoning

That can waste host resources and make acquisition cumbersome. Choose enough resolution and duration to answer the question.

Reference trail: K2K3K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 017

Your first capture: remove the trigger

A trigger is useful only after you know a signal exists. Begin with no trigger condition. Press the single-acquisition control, let the planned record complete, and inspect the result. A finite acquisition avoids the visual confusion of a continuously refreshing display.

A flat line is still evidence. HIGH can mean a legitimate idle state, a pull-up, the wrong pin, or a threshold below the actual low level. LOW can mean no power, a held-low signal, or an incorrect connection. Check one cause at a time. The instrument cannot distinguish “nothing happened” from “you watched the wrong wire” without additional context.

Once a repeating signal is visible, set CH0 to a rising-edge trigger and capture again. The trigger now aligns a meaningful event instead of acting as an obstacle. Use automatic repeat acquisition only for observations where replacing the previous record is acceptable. Stop it before inspecting a rare anomaly.

At the bench · do this next

  1. Acquire once with all trigger conditions cleared.
  2. Fit the record to the screen and identify activity.
  3. Set a single rising edge on a known active channel; acquire again.

Pause & predict

KingstVIS waits indefinitely after adding a trigger. Is that necessarily a software crash?
Reveal the reasoning

No. The required event may never occur. Clear other conditions, check the active edge and trigger again.

Reference trail: K2K3K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 018

Zoom, pan and place the timing markers

Fit the entire record first; then zoom toward one useful burst. The published manual describes wheel zoom, click-to-zoom and dragging to pan. Toolbar controls also provide zoom and a return to time zero. Use the method that works in your installed version; the goal is to retain orientation while moving between overview and detail.

Hover over a pulse to inspect width, period, duty and frequency in the measurement panel. For an interval between different channels, place timing markers A1 and A2 at the chosen events. In the manual’s workflow, select the marker label, move into the waveform and click to place it.

Always name the two events being measured. “A1 at UART start-bit falling edge; A2 at response start-bit falling edge” is reproducible. “About 200 µs somewhere here” is not. Zoom far enough that you select the intended edge, and report a sensible number of digits based on the sample interval.

PWM period and pulse widthA 1 ms period, with 250 µs HIGHPWMT = 1 ms250 µsFrequency = 1/T = 1 kHz Duty = tHIGH/T = 25%
Idealized example; the horizontal bracket spans one complete repeating period.

At the bench · do this next

  1. Fit the record, then zoom to one pulse.
  2. Measure HIGH width and full period.
  3. Place A1 on a frame edge and A2 on a pulse edge; write what each marker means.

Pause & predict

Why can the period differ from twice the HIGH width?
Reveal the reasoning

Only a 50% duty signal has equal HIGH and LOW durations. Period includes both.

Reference trail: K2K3K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 019

Add a decoder after understanding the wires

In the Analyzers area, open the add menu; use More Analyzers if the desired protocol is not in the recent list. Choose the protocol and map each input by its physical CH number. Configure the communication parameters from your source program or peripheral datasheet.

For UART, that includes baud, data bits, parity, stop bits and inversion. For I²C, assign SDA and SCL and choose an address-display convention. For SPI, assign clock, data directions and enable/chip-select, then choose bit order, word length, clock polarity and sampling phase. Later sections explain these choices in detail.

After decoding, compare one annotation with the raw bits. Open Decoded Results to navigate transactions and choose a useful display format from the analyzer menu. Hexadecimal is convenient for register data; ASCII helps with text, but arbitrary bytes do not become meaningful text merely because you switch formats.

At the bench · do this next

  1. Add the decoder matching your loaded example.
  2. Verify every channel assignment against your notebook.
  3. Decode one known byte manually before trusting the remaining result table.

Pause & predict

Can changing display format from hex to ASCII repair corrupted data?
Reveal the reasoning

No. It changes presentation of the same decoded value, not the measurement or protocol interpretation.

Reference trail: K2K3K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 020

Save evidence you can reopen

Kingst’s manual distinguishes settings files from captured data. Save Settings produces a .kvset configuration. Save data produces a .kvdat record with captured data and settings. Use the application’s Open command to revisit them. A configuration alone contains no proof that the circuit behaved as expected.

For analysis elsewhere, the main menu’s Export data handles sample data; the individual analyzer’s Export Data handles decoded results. They answer different questions. A decoded CSV is easy to search for bytes, but the raw capture is what lets you change decoder settings later and investigate a missing edge.

Save an unfiltered baseline and a text notebook entry before experimenting. Include the software version and actual recorded range. When exporting only a selected interval or selected channels, say so in the filename or notes. Reopen your first file immediately to verify that the saved artifact contains the signal and settings you intended.

At the bench · do this next

  1. Save the working configuration as a .kvset.
  2. Save a completed acquisition as a .kvdat.
  3. Export one decoded table, then reopen the raw capture and verify its duration.

Pause & predict

Which file should accompany a puzzling UART decode sent to a colleague?
Reveal the reasoning

The raw .kvdat plus settings/context. A decoded CSV and screenshot are useful additions, but do not replace the source capture.

Reference trail: K2K3K4 · Expected waveforms are teaching predictions, not measured records.
Section 03 · Chapters 021–030

Your first UNO R4 WiFi captures

Make a signal you can explain

The main Arduino sketch runs on the Renesas RA4M1. These header experiments use its 5 V logic. The ESP32-S3 companion and Qwiic connector live in a different voltage domain.

021 Two processors, two voltage domains 022 Upload a known pulse source 023 Wire your first two-channel experiment 024 Read a waveform as a story 025 Trigger on the beginning of a job 026 Discover real PWM on D6 027 Catch a bouncing button 028 Measure latency without confusing it with execution time 029 Use marker pins as a tiny trace system 030 UNO checkpoint: defend your evidence
Chapter 021

Two processors, two voltage domains

The UNO R4 WiFi contains a Renesas RA4M1 main processor and an ESP32-S3-MINI-1-N8 companion module. Selecting “Arduino UNO R4 WiFi” in the Arduino board package ordinarily builds your sketch for the RA4M1. It does not turn the board into a generic ESP32 development kit.

The ordinary UNO digital headers operate in the board’s 5 V domain. The ESP header and Qwiic connector use 3.3 V signals. Arduino explicitly warns against applying 5 V to the ESP header or Qwiic connector. An onboard level translator serves specific internal connections; it does not protect every wire you attach externally.

This distinction controls where you probe, which threshold you choose and which software API corresponds to a wire. The Arduino pinout is the physical authority; source A2 links it. The drawings here simplify board shapes and connector positions for readability. Use their labels and connection tables, then confirm the real silkscreen before attaching hooks.

UNO R4 WiFi voltage and processor domainsRA4M1Main Arduino sketchOrdinary headers: 5 VESP32-S3Wi-Fi / USB bridgeESP header: 3.3 VOnboard leveltranslationQwiic: separate 3.3 V bus, Wire1. Ordinary SDA/SCL headers: Wire.
Functional architecture, not a complete schematic. Onboard translation protects specific internal nets, not every external connection.

At the bench · do this next

  1. Identify RA4M1, ESP module, ordinary headers, and Qwiic on the board.
  2. Find D7 and a GND header for the first lab.
  3. Set a 2.5 V threshold for clean 5 V header signals.

Pause & predict

Does an ESP32-S3 GPIO number correspond to an Arduino D-pin number?
Reveal the reasoning

No. They are different processors and naming systems. D7 in these sketches is a main-board Arduino pin.

Reference trail: A1A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 022

Upload a known pulse source

Open Arduino IDE, install/select the board package that provides UNO R4 WiFi, select the board and its port, then upload the complete pulse sketch below. Remove shields and peripheral wiring for this baseline. This example uses D7 for a short pulse and D8 as a surrounding frame marker.

D7 is HIGH for a requested 250 µs and LOW for a requested 750 µs. D8 brackets that work, then a roughly 9 ms gap follows. Software calls add overhead, so predict “approximately 250 µs” rather than pretending delay calls define exact electrical edge times. The resulting D7 repetition interval is roughly 10 ms, not 1 ms.

After upload, power the board down, attach probes according to Chapter 23, then power it again. You now have a known signal with two useful timescales: a short pulse and a longer frame. That is enough to learn almost every basic capture operation without an external component.

UNO R4 WiFi probe mapUNO R4 WiFiRA4M1 · 5 V header signalsKINGST LA1010INPUTS · passive probesD7 · pulseCH0D8 · frameCH1GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
D7 · pulseCH0
D8 · frameCH1
GNDGND
uno_pulse.ino
UNO R4 WiFi · two timing signals · D7 and D8
Read the complete program
// Upload with board "Arduino UNO R4 WiFi" selected.
void setup() {
  pinMode(7, OUTPUT); pinMode(8, OUTPUT);
  digitalWrite(7, LOW); digitalWrite(8, LOW);
}
void loop() {
  digitalWrite(8, HIGH);       // frame marker
  digitalWrite(7, HIGH); delayMicroseconds(250);
  digitalWrite(7, LOW);  delayMicroseconds(750);
  digitalWrite(8, LOW);
  delay(9);                   // roughly 10 ms per frame, plus overhead
}

At the bench · do this next

  1. Select UNO R4 WiFi and upload uno_pulse.ino.
  2. Power down before attaching the probe harness.
  3. Capture about 100 ms at 1 MS/s with no trigger initially.

Pause & predict

Why is D7 not a 1 kHz square wave in this example?
Reveal the reasoning

There is a 9 ms delay after the 1 ms work interval. Its pulses recur roughly every 10 ms.

Reference trail: A1A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 023

Wire your first two-channel experiment

Attach CH0 to D7 and CH1 to D8. Attach an analyzer GND to an UNO GND header. The board receives power through its own USB cable; there is no power wire from the analyzer to the UNO. Three measurement connections are sufficient.

Keep the leads short and avoid dangling hooks that can contact neighboring pins. Power off while repositioning them. Since both signals belong to the same voltage domain, the 2.5 V threshold is a sensible initial choice. Rename the traces PULSE_D7 and FRAME_D8 rather than relying on cable colors.

Read the expected causality: D8 rises first, then D7 rises; D7 falls about 250 µs later; D8 falls after the rest of the 1 ms work interval. Small separations between calls are real overhead. If the broad and narrow traces are swapped, check your channel mapping before changing the sketch.

UNO R4 WiFi probe mapUNO R4 WiFiRA4M1 · 5 V header signalsKINGST LA1010INPUTS · passive probesD7 · pulseCH0D8 · frameCH1GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
D7 · pulseCH0
D8 · frameCH1
GNDGND

At the bench · do this next

  1. Connect GND→GND, CH0→D7, CH1→D8 with target power off.
  2. Enable exactly CH0 and CH1, threshold 2.5 V.
  3. Power up and capture; identify the narrow pulse inside the wider marker.

Pause & predict

Both labels look reversed. What is the quickest non-destructive check?
Reveal the reasoning

Compare physical CH numbers to the wires, then correct the channel names or decoder mapping.

Reference trail: A1A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 024

Read a waveform as a story

A trace becomes useful when you narrate it. “The frame marker rises. The pulse starts. The pulse ends. The frame ends. The board waits.” This maps observations back to program structure without requiring you to guess every machine instruction.

Place A1 at D8’s rising edge and A2 at D7’s rising edge. That interval includes the time between the two output operations as they appear electrically. It is not simply the CPU’s execution time for one C statement; function calls, implementation details, interrupts and output synchronization can contribute.

Now measure the D7 HIGH width, D8 HIGH width and D8 period. These are three different quantities. Compare each with its own prediction. A 250 µs HIGH pulse in a 10 ms frame has about 2.5% duty over that whole frame, even though the inner work interval lasts 1 ms. Always specify which repeating period you mean.

PWM period and pulse widthA 1 ms period, with 250 µs HIGHPWMT = 1 ms250 µsFrequency = 1/T = 1 kHz Duty = tHIGH/T = 25%
Idealized example; the horizontal bracket spans one complete repeating period.

At the bench · do this next

  1. Measure D7 HIGH width, D8 HIGH width, and frame period.
  2. Calculate D7 duty using the actual frame period.
  3. Annotate which source statements correspond to each edge.

Pause & predict

What does a 250 µs pulse every 10 ms imply?
Reveal the reasoning

Approximately 100 Hz repetition and 2.5% duty cycle. The pulse width itself is not the frequency.

Reference trail: A1A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 025

Trigger on the beginning of a job

Remove previous trigger conditions, then put a rising-edge condition on CH1, the frame marker. Start a single acquisition. The capture should align on the beginning of a frame, making repeated records easier to compare.

A marker pin is often better than triggering on arbitrary data because you control what it means. A UART data line can fall many times inside a message; a dedicated marker can mean “new request begins.” Keep that interpretation consistent in your firmware.

If the frame has already started before you arm, the analyzer will wait for the next matching edge. That is expected. For one-shot startup code, arm first and then press the target reset button. Do not unplug the analyzer to reset the target. A trigger observes the selected condition; it does not tell the program to run or guarantee that every later event will fit inside the window.

At the bench · do this next

  1. Set CH1 rising-edge as the only condition.
  2. Acquire three frames separately and compare their alignment.
  3. Try CH1 falling-edge and explain how the event position changes.

Pause & predict

Can a rising-edge trigger fire while the signal is already HIGH and stays HIGH?
Reveal the reasoning

An edge trigger needs a transition. Use a level trigger only if a level condition is the event you actually want.

Reference trail: A1A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 026

Discover real PWM on D6

Upload the PWM staircase example and move CH0 to D6. The sketch requests roughly 25%, 50% and 75% duty, holding each for one second. Capture a few milliseconds within one plateau to measure the waveform, then use a longer record to observe the changes.

analogWrite() on a PWM-capable digital pin changes pulse duty; it does not produce a steady analog voltage. The exact carrier frequency and endpoint behavior depend on the board core implementation. Measure the period instead of borrowing a default frequency from an UNO R3 tutorial.

For an 8-bit request, 64, 128 and 192 are convenient approximate duty steps, not mathematical guarantees of exact 25.000%, 50.000% and 75.000% output. Inspect the actual timer result. A motor driver may interpret PWM as average drive, but the analyzer sees the fast switching command, not mechanical speed or motor current.

PWM period and pulse widthA 1 ms period, with 250 µs HIGHPWMT = 1 ms250 µsFrequency = 1/T = 1 kHz Duty = tHIGH/T = 25%
Idealized example; the horizontal bracket spans one complete repeating period.
uno_pwm.ino
UNO R4 WiFi · hardware PWM staircase on D6
Read the complete program
void setup() { pinMode(6, OUTPUT); analogWriteResolution(8); }
void loop() {
  analogWrite(6, 64);  delay(1000);
  analogWrite(6, 128); delay(1000);
  analogWrite(6, 192); delay(1000);
}

At the bench · do this next

  1. Upload uno_pwm.ino and probe D6 with common ground.
  2. Measure duty and period in each plateau.
  3. Compare whether the period stays stable while HIGH width changes.

Pause & predict

Will a logic analyzer show a steady 2.5 V for 50% PWM on a 5 V pin?
Reveal the reasoning

No. It shows alternating HIGH and LOW. An averaged voltage reading is a different measurement.

Reference trail: A1A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 027

Catch a bouncing button

Wire a pushbutton between D2 and GND and load the button example. INPUT_PULLUP makes the released state HIGH; pressing connects the input to ground. Probe CH0 at D2, CH1 at D7 and CH2 at D8. The program copies the sampled raw state to D7 and its debounced decision to D8.

Mechanical contacts may open and close several times during one press. Capture about 100 ms around a falling edge on D2 at 1 MS/s. A single physical gesture can therefore appear as a short burst of transitions. Your switch may bounce differently on release, or barely bounce in one trial.

The raw mirror D7 is sampled by software and cannot reproduce edges faster than the loop observes. D2 is the direct electrical evidence. The debouncer requires a candidate state to remain stable for at least 20 ms before accepting it; D8 should make one delayed transition. This intentional latency buys immunity to brief reversals.

UNO R4 WiFi probe mapUNO R4 WiFiButton: D2 to GND · INPUT_PULLUPKINGST LA1010INPUTS · passive probesD2 · electrical inputCH0D7 · raw mirrorCH1D8 · accepted stateCH2GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
D2 · electrical inputCH0
D7 · raw mirrorCH1
D8 · accepted stateCH2
GNDGND
uno_button.ino
UNO R4 WiFi · raw and debounced button · D2 to GND
Read the complete program
const uint8_t buttonPin=2, rawPin=7, stablePin=8;
bool candidate=HIGH, stable=HIGH;
uint32_t changedAt=0;
void setup() {
  pinMode(buttonPin, INPUT_PULLUP);
  pinMode(rawPin, OUTPUT); pinMode(stablePin, OUTPUT);
}
void loop() {
  bool raw=digitalRead(buttonPin);
  digitalWrite(rawPin, raw);
  if (raw!=candidate) { candidate=raw; changedAt=millis(); }
  if (uint32_t(millis()-changedAt)>=20) stable=candidate;
  digitalWrite(stablePin, stable);
}

At the bench · do this next

  1. Use a button only between D2 and GND; no external supply is needed.
  2. Trigger on D2 falling, capture several presses and releases.
  3. Compare electrical input, raw software mirror and accepted state.

Pause & predict

Why might D2 show an edge that D7 misses?
Reveal the reasoning

The loop did not sample that brief state. D7 is a software observation, not a perfect electrical duplicate.

Reference trail: A1A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 028

Measure latency without confusing it with execution time

Latency is the time from a chosen event to a response. Execution time is the duration of a chosen piece of work. The button example exposes both sampling delay and deliberate debounce delay, but those are not interchangeable.

Put A1 on the final bounce edge after which D2 stays LOW. Put A2 on D8’s accepted LOW transition. Expect about 20 ms or slightly more, with loop and millisecond-tick effects. Measuring from the very first contact instead includes the bouncing interval as well.

Repeat several times and record minimum, maximum and typical values. One capture proves one occurrence. It does not establish a worst-case guarantee. In a more complex program, serial logging or network calls can delay polling, so the measured range may widen. Change one workload at a time and keep the input method as consistent as practical.

At the bench · do this next

  1. Measure first-contact→accepted-state and final-bounce→accepted-state separately.
  2. Record ten trials in a small table.
  3. Explain the difference using the debounce algorithm.

Pause & predict

A 20 ms debounce rule sometimes gives 24 ms from first contact. Is it necessarily wrong?
Reveal the reasoning

No. Initial bouncing plus sampling and tick timing can add delay. Measure from the last candidate change as well.

Reference trail: A1A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 029

Use marker pins as a tiny trace system

A spare GPIO can announce that firmware entered a state, started a transaction or detected an error. Assign meanings before adding markers: D7 HIGH means “inside this operation,” while a short pulse on D8 might mean “timeout occurred.” Capture those markers beside the relevant bus.

Markers cost execution time and use pins. Keep them simple, avoid pins already used by a peripheral, and compare behavior with instrumentation removed when timing is tight. Printing a sentence over serial usually perturbs timing much more than a single output change, but neither is free.

A marker around an asynchronous call measures the call’s duration, which may only enqueue work. To measure completion, place the closing marker at a completion flag, callback, or hardware transmission-complete check. The UART examples later demonstrate why “buffer accepted my bytes” and “last stop bit left the wire” are distinct events.

At the bench · do this next

  1. Choose one operation with a clear start and finish.
  2. Reserve a spare pin and document its meaning.
  3. Capture the marker and the external effect on the same acquisition.

Pause & predict

A marker goes LOW before UART transmission finishes. What could that mean?
Reveal the reasoning

The API returned after queuing bytes, or you measured TX-buffer availability rather than physical transmission completion.

Reference trail: A1A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 030

UNO checkpoint: defend your evidence

You can now upload a source, connect a reference, choose acquisition settings and measure a known pulse. Consolidate those skills by rebuilding the first pulse experiment from a blank KingstVIS configuration, using only your notes.

Your evidence bundle should contain the raw capture, a view of one frame, the sketch, channel map and three measurements. State the source of expected timing and why the observed numbers need not be exact. Explicitly distinguish a commanded delay from the total period between physical edges.

For a fault exercise, change only the sketch’s 250 µs delay to 500 µs. Predict how D7 width, D8 width and the overall frame period change while the other delays remain fixed. Capture, compare and restore the original sketch. A successful explanation identifies every affected interval rather than saying only “the pulse got bigger.”

At the bench · do this next

  1. Rebuild and save the baseline without copying an old configuration.
  2. Change the HIGH delay to 500 µs and predict all three intervals.
  3. Capture, explain the differences, then restore the baseline.

Pause & predict

What happens to the approximate frame period after that change?
Reveal the reasoning

It increases by about 250 µs because the other delays stay unchanged. D8’s HIGH interval grows too.

Reference trail: A1A2A5 · Expected waveforms are teaching predictions, not measured records.
Section 04 · Chapters 031–040

STM32F411RE: registers become waveforms

CMSIS C, with the clock made explicit

These programs target NUCLEO-F411RE in an empty CMSIS project. They use the nominal 16 MHz HSI clock to make timing calculations transparent. They are complete main.c examples, not code fragments to paste into an unrelated HAL clock configuration.

031 Find the pin through three layers of names 032 Prepare the CMSIS project once 033 Drive PA5 with BSRR 034 Understand the clock before trusting the formula 035 Make hardware PWM with TIM3 036 The alternate-function mistake that looks like dead hardware 037 Compare software delay with a peripheral timer 038 Use the debugger without freezing your experiment 039 Route UART away from the ST-LINK bridge 040 STM32 checkpoint: derive a waveform from registers
Chapter 031

Find the pin through three layers of names

The MCU signal name, board header label and analyzer channel name are different layers. For example, PA6 is a pin of GPIO port A; on NUCLEO-F411RE it reaches Arduino-style D12; your CH0 probe can observe it. Calling a trace “D12” does not configure PA6.

The same MCU pad may support GPIO, analog input and several peripheral alternate functions. Your firmware must select the intended function. A correctly configured timer that has not been routed to a pin can count internally while the header remains flat.

Use the Nucleo manual’s F411RE-specific connector table and the STM32 datasheet’s alternate-function table together. The principal mappings in this guide are PA5/D13, PA6/D12, PA7/D11, PA9/D8, PB6/D10, PB8/D15/SCL and PB9/D14/SDA. Labels A4/A5 on Nucleo are not a safe substitute for the dedicated I²C pins without checking bridge routing.

NUCLEO-F411RE probe mapNUCLEO-F411RESignal-name translationKINGST LA1010INPUTS · passive probesPA5 → D13Example CH0PA6 → D12Example CH1PA9 → D8Example CH2GNDGNDNames shown are verified routes; channel assignments depend on the lab.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
PA5 → D13Example CH0
PA6 → D12Example CH1
PA9 → D8Example CH2
GNDGND

At the bench · do this next

  1. Find D13/PA5 and a GND on your Nucleo.
  2. Write MCU pin→header→analyzer channel in your notebook.
  3. Check that the selected pin is not being used by another attached board.

Pause & predict

Does setting TIM3 registers automatically make every TIM3-capable pin output PWM?
Reveal the reasoning

No. The chosen pin needs its GPIO clock, alternate-function mode and correct AF selection.

Reference trail: S1S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 032

Prepare the CMSIS project once

Create an empty C project for STM32F411RE using your CubeIDE CMSIS setup. Include stm32f4xx.h and define STM32F411xE. Retain the correct startup file, linker script and one system implementation providing SystemInit and SystemCoreClock. The examples intentionally avoid HAL initialization.

Each downloadable STM32 program is a complete replacement main.c. Do not combine their main functions. Do not leave a second clock initializer that switches to a PLL after the example sets HSI. Cleanly separate compile problems, link problems and physical observation: a missing header is not a wiring issue, while a flat pin after a successful flash is not fixed by adding include paths.

The shared helper switches the system to HSI and selects undivided AHB/APB buses. It also enables GPIOA/GPIOB and the Cortex-M cycle counter used for short delays. This makes the nominal timing base explicit. The internal RC clock has tolerance; measurements need not match an ideal 16 MHz crystal perfectly.

At the bench · do this next

  1. Create the empty target project and verify its device macro.
  2. Replace main.c with one complete checkpoint program.
  3. Build, flash, let it run freely and reset before measuring.

Pause & predict

Why must SystemInit not be defined in two source files?
Reveal the reasoning

The linker normally reports duplicate definitions. Keep one board startup/system implementation and let the example configure its intended runtime clock.

Reference trail: S1S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 033

Drive PA5 with BSRR

Load the STM32 pulse example. PA5, available at D13, also drives the Nucleo’s user LED. The pulse is too fast for your eyes to judge accurately, which is exactly why the analyzer is useful. Connect CH0 to D13 and ground to GND; start with a 1.5 V threshold.

The GPIO clock gate allows register access to affect the port. MODER selects output mode for PA5. BSRR writes set and reset actions without a read-modify-write sequence: bit 5 sets PA5, and bit 21 resets it. This avoids disturbing other pins merely to change one output.

The cycle-counter delay uses nominal CPU cycles, but function and register-access overhead still separates physical edges. Expect roughly 250 µs HIGH and 750 µs LOW, repeating around 1 ms. Unlike the UNO frame example, this program has no extra 9 ms gap. Compare the two programs by their code paths, not their similar-looking delay numbers.

NUCLEO-F411RE probe mapNUCLEO-F411REGPIO · 3.3 V signalsKINGST LA1010INPUTS · passive probesD13 · PA5CH0GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
D13 · PA5CH0
GNDGND
stm_pulse_main.c
NUCLEO-F411RE · PA5/D13 pulse · nominal 16 MHz HSI
Read the complete program
#include "stm32f4xx.h"
#include <stdint.h>
// Empty STM32F411RE CMSIS project. No HAL_Init or HAL clock setup.
// Retain startup, linker script and exactly one SystemInit/SystemCoreClock source.
static void init16(void) {
  RCC->CR |= RCC_CR_HSION;
  while (!(RCC->CR & RCC_CR_HSIRDY)) {}
  RCC->CFGR &= ~RCC_CFGR_SW;   // select HSI before changing divisors
  while ((RCC->CFGR & RCC_CFGR_SWS)!=0u) {}
  RCC->CFGR = 0u;             // HCLK, PCLK1, PCLK2 = nominal 16 MHz
  SystemCoreClock = 16000000u;
  RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN | RCC_AHB1ENR_GPIOBEN;
  (void)RCC->AHB1ENR;
  CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
  DWT->CYCCNT=0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
}
static void us(uint32_t n) {
  uint32_t start=DWT->CYCCNT;
  while ((uint32_t)(DWT->CYCCNT-start)<n*16u) {}
}
static void output(GPIO_TypeDef *p,unsigned pin) {
  p->MODER=(p->MODER & ~(3u<<(pin*2))) | (1u<<(pin*2));
  p->OTYPER &= ~(1u<<pin);
  p->PUPDR &= ~(3u<<(pin*2));
}
static void af(GPIO_TypeDef *p,unsigned pin,unsigned f) {
  p->MODER=(p->MODER & ~(3u<<(pin*2))) | (2u<<(pin*2));
  p->OTYPER &= ~(1u<<pin);
  p->PUPDR &= ~(3u<<(pin*2));
  p->OSPEEDR=(p->OSPEEDR & ~(3u<<(pin*2))) | (2u<<(pin*2));
  unsigned shift=(pin%8u)*4u;
  p->AFR[pin/8u]=(p->AFR[pin/8u] & ~(15u<<shift)) | (f<<shift);
}

int main(void) {
  init16(); output(GPIOA,5);
  while (1) {
    GPIOA->BSRR=1u<<5; us(250);
    GPIOA->BSRR=1u<<(5+16); us(750);
  }
}

At the bench · do this next

  1. Build and flash stm_pulse_main.c.
  2. Probe PA5/D13, GND; acquire at 1 MS/s for about 20 ms.
  3. Measure HIGH, LOW and period, then calculate duty.

Pause & predict

What BSRR bit resets PA5?
Reveal the reasoning

Bit 5+16 = 21. The upper half of BSRR carries reset requests.

Reference trail: S1S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 034

Understand the clock before trusting the formula

A peripheral clock is not always the CPU clock. STM32 has a clock tree with AHB and APB buses, prescalers and timer-specific behavior. Copying a baud divisor from a 100 MHz project into a 16 MHz project changes the waveform.

In this guide’s checkpoint programs, HCLK, PCLK1 and PCLK2 are nominally 16 MHz and the APB prescalers are one. That makes TIM3’s timer clock 16 MHz as well. In other clock trees, the timer clock can be twice its APB clock when the APB prescaler is not one; consult RM0383 rather than assuming.

A measured frequency error can expose a wrong clock assumption. If every timing interval is off by the same scale factor, inspect the clock tree first. If only one peripheral is wrong, inspect its local divider and mode. A tiny consistent discrepancy may simply reflect HSI tolerance and measurement resolution; an exact factor of two usually deserves configuration investigation.

Timer clock calculationTIM3 example: every divider is visibleHSI16 MHzAPB1 /116 MHzPSC + 1 = 161 MHz ticksARR + 1 = 10001 kHz PWMCCR1 = 250 → HIGH for 250 of the 1000 ticks → 25% duty
This applies to the explicit 16 MHz, undivided-bus checkpoint. Other clock trees require recalculation.

At the bench · do this next

  1. Write HCLK, PCLK1, PCLK2 and TIM3 clock for this program.
  2. Calculate the expected pulse repetition before capturing.
  3. If it differs strongly, inspect RCC and peripheral dividers in the debugger.

Pause & predict

Why might a timer run twice as fast as a calculation using PCLK1?
Reveal the reasoning

The APB prescaler/timer-clock rule may have been omitted. Always use the actual timer input clock.

Reference trail: S1S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 035

Make hardware PWM with TIM3

Load the TIM3 example and move CH0 to PA6/D12. AF2 connects this pad to TIM3 channel 1. A timer counts repeatedly, compares its counter with CCR1 and generates PWM without a software loop toggling the pin.

With a 16 MHz timer clock, PSC=15 divides by 16, yielding a 1 MHz counter tick. ARR=999 gives 1000 ticks per period, or 1 ms. CCR1=250 in PWM mode 1 produces a HIGH interval of 250 ticks, giving nominally 1 kHz at 25% duty. The “plus one” in PSC+1 and ARR+1 matters.

The preload settings stage values for a controlled update; EGR.UG loads the initial configuration before the timer starts. The main loop then waits while hardware continues. This is a powerful separation: CPU workload and output timing need not be the same thing. Capture at 10 MS/s to see the regularity clearly, without claiming the analyzer proves zero jitter.

PWM period and pulse widthA 1 ms period, with 250 µs HIGHPWMT = 1 ms250 µsFrequency = 1/T = 1 kHz Duty = tHIGH/T = 25%
Idealized example; the horizontal bracket spans one complete repeating period.
stm_pwm_main.c
NUCLEO-F411RE · TIM3_CH1 on PA6/D12 · 1 kHz, 25%
Read the complete program
#include "stm32f4xx.h"
#include <stdint.h>
// Empty STM32F411RE CMSIS project. No HAL_Init or HAL clock setup.
// Retain startup, linker script and exactly one SystemInit/SystemCoreClock source.
static void init16(void) {
  RCC->CR |= RCC_CR_HSION;
  while (!(RCC->CR & RCC_CR_HSIRDY)) {}
  RCC->CFGR &= ~RCC_CFGR_SW;   // select HSI before changing divisors
  while ((RCC->CFGR & RCC_CFGR_SWS)!=0u) {}
  RCC->CFGR = 0u;             // HCLK, PCLK1, PCLK2 = nominal 16 MHz
  SystemCoreClock = 16000000u;
  RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN | RCC_AHB1ENR_GPIOBEN;
  (void)RCC->AHB1ENR;
  CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
  DWT->CYCCNT=0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
}
static void us(uint32_t n) {
  uint32_t start=DWT->CYCCNT;
  while ((uint32_t)(DWT->CYCCNT-start)<n*16u) {}
}
static void output(GPIO_TypeDef *p,unsigned pin) {
  p->MODER=(p->MODER & ~(3u<<(pin*2))) | (1u<<(pin*2));
  p->OTYPER &= ~(1u<<pin);
  p->PUPDR &= ~(3u<<(pin*2));
}
static void af(GPIO_TypeDef *p,unsigned pin,unsigned f) {
  p->MODER=(p->MODER & ~(3u<<(pin*2))) | (2u<<(pin*2));
  p->OTYPER &= ~(1u<<pin);
  p->PUPDR &= ~(3u<<(pin*2));
  p->OSPEEDR=(p->OSPEEDR & ~(3u<<(pin*2))) | (2u<<(pin*2));
  unsigned shift=(pin%8u)*4u;
  p->AFR[pin/8u]=(p->AFR[pin/8u] & ~(15u<<shift)) | (f<<shift);
}

int main(void) {
  init16(); af(GPIOA,6,2);     // PA6 AF2 = TIM3_CH1
  RCC->APB1ENR |= RCC_APB1ENR_TIM3EN; (void)RCC->APB1ENR;
  TIM3->CR1=0; TIM3->PSC=15; TIM3->ARR=999; TIM3->CCR1=250;
  TIM3->CCMR1=(6u<<4) | TIM_CCMR1_OC1PE; // PWM mode 1, preload
  TIM3->CCER=TIM_CCER_CC1E;
  TIM3->CR1=TIM_CR1_ARPE;
  TIM3->EGR=TIM_EGR_UG; TIM3->SR=0;
  TIM3->CR1 |= TIM_CR1_CEN;
  while (1) { __WFI(); }     // timer keeps working
}

At the bench · do this next

  1. Flash stm_pwm_main.c and probe PA6/D12.
  2. Measure 250 µs HIGH and 1 ms period approximately.
  3. Change CCR1 to 500, rebuild, and predict the period remains the same.

Pause & predict

What is the nominal frequency with PSC=15 and ARR=1999?
Reveal the reasoning

16 MHz/(16×2000) = 500 Hz.

Reference trail: S1S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 036

The alternate-function mistake that looks like dead hardware

Three independent gates stand between a timer and a header: the peripheral must be clocked and enabled, its channel output must be enabled, and the GPIO pad must select the correct alternate function. A failure in any one can leave a flat line.

Use the working TIM3 example as a baseline. For a controlled fault, change PA6’s AF selection from 2 to an unrelated value, rebuild and observe the pin. Restore AF2 afterward. The timer registers can still show counting even though its signal no longer reaches the pad. This distinguishes internal activity from external routing.

When debugging a real board, inspect RCC clock enable, GPIO MODER and AFR, timer CCER, and the selected compare mode. Check the physical header separately. A register dump plus a capture provides stronger evidence than either alone. Do not solve a route error by endlessly changing the analyzer’s threshold.

At the bench · do this next

  1. Save a working PWM capture.
  2. Introduce one AF-selection error, observe, then restore it.
  3. Explain why CNT can change while the output pin is quiet.

Pause & predict

If the pin is in normal GPIO output mode, will a valid timer compare register necessarily appear there?
Reveal the reasoning

No. The pad must be switched to the timer’s alternate function.

Reference trail: S1S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 037

Compare software delay with a peripheral timer

Run the GPIO pulse program and the TIM3 PWM program separately, saving a capture from each. Both aim for roughly 1 kHz and 25% duty, but one derives its edges from software reaching statements and the other from a peripheral counter.

For each record, measure several periods. Software timing includes loop overhead and can be stretched by interrupts. Hardware timer output generally continues independently of ordinary CPU instruction scheduling. Its frequency still depends on the timer clock and configuration, so “hardware” does not mean “automatically correct.”

Do not add two unrelated captured traces together as if their absolute time origins matched. Compare distributions or measured periods unless the signals were captured simultaneously under a shared reference. To study jitter properly, use a sufficiently high sample rate and recognize that the analyzer itself quantizes edge times. One-sample alternation may be measurement phase rather than source instability.

At the bench · do this next

  1. Capture ten periods of each program at the same rate.
  2. Record mean-looking period and observed minimum/maximum.
  3. Explain whether the spread exceeds the measurement resolution.

Pause & predict

Does a one-sample change in displayed pulse width prove firmware jitter?
Reveal the reasoning

No. Sample alignment and threshold behavior can account for small changes. Increase resolution and repeat before concluding.

Reference trail: S1S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 038

Use the debugger without freezing your experiment

Breakpoints are excellent for checking register setup, but they can disturb the event you are trying to measure. The core may halt while a timer continues, or a debug-freeze setting may stop a peripheral. A paused program is not the same system as a free-running one.

Use a two-stage workflow. First halt after initialization and inspect RCC, GPIO and peripheral registers. Then resume, clear breakpoints that would interfere, reset if needed and make a clean capture. Document whether the debugger was attached and whether any freeze options were enabled.

The cycle counter used for delays is also tied to core execution/debug behavior. A pause during a timing loop can invalidate a latency observation. For an intermittent external problem, use marker pins and free-running acquisition rather than stepping through the transaction one instruction at a time.

At the bench · do this next

  1. Inspect initialization once with the debugger.
  2. Resume or reset into uninterrupted execution.
  3. Acquire the timing record with no breakpoint hit inside the observed interval.

Pause & predict

A pulse stretches to seconds while stepping. Is that evidence of a production timing fault?
Reveal the reasoning

No. Debugger intervention changed execution. Reproduce it without halting the core.

Reference trail: S1S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 039

Route UART away from the ST-LINK bridge

NUCLEO-F411RE has an ST-LINK virtual COM connection involving USART2 and PA2/PA3. The board’s solder bridges affect how those signals reach Arduino-style D1/D0 and other connections. A generic “probe D1” instruction can therefore mislead you on an unmodified board.

The UART checkpoint in this guide instead uses USART1 TX on PA9, available at D8, with AF7. PB6/D10 becomes a marker. This avoids asking you to modify solder bridges merely to learn UART decoding. It also avoids accidental contention with an ST-LINK-driven receive path.

If you later choose USART2, consult your board revision’s schematic and UM1724 bridge table. Don’t remove or bridge components casually. Verify routing with the board unpowered and a continuity meter, and distinguish an MCU pin from a header label that may be disconnected. Source S1 documents this board-specific trap.

NUCLEO-F411RE probe mapNUCLEO-F411REUSART1 · 3.3 V signalsKINGST LA1010INPUTS · passive probesD8 · PA9 TXCH0D10 · PB6 markerCH1GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
D8 · PA9 TXCH0
D10 · PB6 markerCH1
GNDGND

At the bench · do this next

  1. Locate PA9/D8 and PB6/D10.
  2. Reserve those pins for the UART chapter.
  3. Leave ST-LINK solder bridges unchanged for this course’s baseline.

Pause & predict

Why choose USART1 here when many tutorials use USART2?
Reveal the reasoning

It gives a straightforward header route for this lab without relying on the USART2/ST-LINK solder-bridge configuration.

Reference trail: S1S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 040

STM32 checkpoint: derive a waveform from registers

Take the TIM3 program and write its signal path in one sentence: 16 MHz HSI clock, bus clock gate, timer divider, counter period, compare threshold, channel enable, PA6 alternate function, D12 header, CH0 probe. This is the chain you should be able to reconstruct in future projects.

Now make a specific target: 500 Hz with 30% duty. Keep PSC=15, set ARR=1999 and set CCR1=600. Predict 2 ms period and 600 µs HIGH. Build, flash and measure. If the output is wrong, use the chain to localize the fault instead of editing several settings at once.

Save the source and raw capture. State nominal clock assumptions and measured values. You have reached the point where a register is no longer just a number in a debugger; it predicts a visible electrical behavior. Later UART and SPI chapters apply the same method to more structured waveforms.

At the bench · do this next

  1. Derive the 500 Hz, 30% settings on paper.
  2. Modify only ARR and CCR1, then capture.
  3. Restore the original checkpoint after saving your evidence.

Pause & predict

Why is CCR1=600 appropriate with ARR=1999?
Reveal the reasoning

There are 2000 counter ticks per period; 600/2000 = 30% for the chosen edge-aligned PWM mode.

Reference trail: S1S2S3 · Expected waveforms are teaching predictions, not measured records.
Section 05 · Chapters 041–050

UART: read the wire yourself

From a falling edge to a trustworthy byte

UART is the ideal first protocol: one data line, a predictable idle state, and a bit period you can measure with two markers. Learn one direction before adding a response.

041 What UART promises—and what it does not 042 Generate four unmistakable UNO bytes 043 Configure the KingstVIS UART analyzer 044 Decode 0xA3 by hand 045 Let the STM32 produce the same message 046 Discover an unknown baud rate 047 Make the decoder wrong on purpose 048 Add a local loopback response 049 Separate framing errors from electrical standards 050 UART checkpoint: prove an entire exchange
Chapter 041

What UART promises—and what it does not

UART sends bits without a separate clock wire. Both ends agree on a baud rate and frame format, then use the start edge to establish timing for each character. For the ordinary non-inverted logic-level UART used here, idle is HIGH and the start bit is LOW.

A common 8N1 frame contains one start bit, eight data bits, no parity bit and one stop bit. It therefore uses ten bit periods to carry eight data bits. At 115200 baud, the ideal bit period is about 8.681 µs and a contiguous character takes about 86.81 µs. Gaps between characters are additional time.

UART framing says nothing about the meaning of a byte. A temperature sensor may send binary values, text or a custom packet. Before interpreting a message, confirm that the electrical timing and frame format are correct. “Readable text” is a useful clue, not a complete protocol specification.

UART bit laboratory · 8N1, LSB first

Generated educational waveform, not a hardware capture.

At the bench · do this next

  1. Sketch the order idle→start→data→stop in your notes.
  2. Calculate bit and frame duration at 9600 and 115200 baud.
  3. Predict the idle state before connecting a transmitter.

Pause & predict

At 115200 baud, can 115200 eight-bit characters fit in one second using 8N1?
Reveal the reasoning

No. Each character needs ten bit periods, giving a theoretical 11520 characters/s before inter-character gaps.

Reference trail: K2A5S2 · Expected waveforms are teaching predictions, not measured records.
Chapter 042

Generate four unmistakable UNO bytes

Upload the UNO UART example and probe D1/TX with CH0. Probe D7 with CH1 for the transaction marker and attach common ground. Set a 2.5 V threshold, at least 10 MS/s if available and about 10 ms of recorded time. Trigger on CH1 rising to capture the complete known burst.

The sketch emits 0x55, 0xA3, 0x00 and 0xFF through Serial1 at 115200 8N1. These patterns exercise alternating bits, an asymmetric byte, a long LOW region and a long HIGH region. The asymmetry is important: patterns such as 0x55 are excellent for measuring bit time but weak for detecting some bit-order mistakes.

Serial1 reaches the external D0/D1 UART pins. Serial is the board’s computer-facing serial path and is not a promise of data on D1. The marker remains HIGH until Serial1.flush returns after outgoing transmission. Compare it with the last stop bit, allowing software overhead around the call.

UNO R4 WiFi probe mapUNO R4 WiFiSerial1 · 5 V header signalsKINGST LA1010INPUTS · passive probesD1 · TXCH0D7 · markerCH1GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
D1 · TXCH0
D7 · markerCH1
GNDGND
uno_uart.ino
UNO R4 WiFi · known UART bytes · D1 TX, D7 marker
Read the complete program
void setup() {
  pinMode(7, OUTPUT); digitalWrite(7, LOW);
  Serial1.begin(115200, SERIAL_8N1);
}
void loop() {
  const uint8_t bytes[]={0x55,0xA3,0x00,0xFF};
  digitalWrite(7, HIGH);
  Serial1.write(bytes, sizeof(bytes));
  Serial1.flush();              // wait for outgoing transmission
  digitalWrite(7, LOW);
  delay(100);
}

At the bench · do this next

  1. Upload uno_uart.ino.
  2. Wire CH0→D1, CH1→D7, GND→GND.
  3. Capture a marker-triggered burst and count four frames.

Pause & predict

Why use 0xA3 as well as 0x55?
Reveal the reasoning

0xA3 is asymmetric, so it helps expose reversed bit interpretation that repetitive patterns can conceal.

Reference trail: K2A5S2 · Expected waveforms are teaching predictions, not measured records.
Chapter 043

Configure the KingstVIS UART analyzer

Add UART/232/485 from the Analyzers menu. The grouped name refers to related serial framing; it does not make all those electrical interfaces identical. For this lab select CH0, 115200 baud, eight data bits, one stop bit, no parity, non-inverted logic and least-significant-bit first. Leave specialized address-flag options off.

Start with a manually specified baud rate because your source is known. Automatic baud detection is an estimate and can misidentify patterns. The current release notes mention changes to auto-baud behavior, another reason to record the software version.

Display hexadecimal first. Expect 55 A3 00 FF in that order. Then switch display format to see why only some bytes look like sensible characters. If the decoder reports framing errors, inspect the start and stop levels at the raw waveform before trying random combinations of settings. Verify a complete frame lies inside the record.

At the bench · do this next

  1. Add UART/232/485 and explicitly set every listed parameter.
  2. Map it to CH0 and choose hexadecimal display.
  3. Compare the decoded sequence against the four source bytes.

Pause & predict

Should “Inverted” be enabled merely because the analyzer menu includes RS232?
Reveal the reasoning

No. These MCU UART signals are non-inverted logic-level signals. Configure the actual observed interface.

Reference trail: K2A5S2 · Expected waveforms are teaching predictions, not measured records.
Chapter 044

Decode 0xA3 by hand

0xA3 in conventional most-significant-bit-written-first notation is 10100011. UART sends the least significant data bit first, so the time sequence after the start bit is 1, 1, 0, 0, 0, 1, 0, 1. Confusing written order with transmission order is a classic first mistake.

Locate the falling start edge. The center of the start bit is half a bit time later; the center of data bit 0 is 1.5 bit times after the edge. Subsequent data centers are spaced by one bit time. Read the eight levels and assign weights 1, 2, 4, 8, 16, 32, 64, 128. For this pattern, 1+2+32+128 = 163.

At the stop-bit center, the line should be HIGH. Don’t count every visible edge as one bit boundary: adjacent equal bits merge into a longer plateau. The 0x00 frame makes this obvious because start plus eight zero data bits form a long LOW region.

UART bit laboratory · 8N1, LSB first

Generated educational waveform, not a hardware capture.

At the bench · do this next

  1. Find the 0xA3 frame and measure one bit time using the 0x55 frame.
  2. Read data at the centers, starting 1.5 bit periods after start.
  3. Sum the bit weights and compare with the annotation.

Pause & predict

Why can a long LOW plateau contain several bits?
Reveal the reasoning

Equal adjacent bits produce no intervening edge. Timing, not edge count alone, defines the bit cells.

Reference trail: K2A5S2 · Expected waveforms are teaching predictions, not measured records.
Chapter 045

Let the STM32 produce the same message

Flash the USART1 program. Connect CH0 to PA9/D8 and CH1 to PB6/D10; use GND and a 1.5 V threshold. Keep the same UART decoder parameters as the UNO lab. The payload remains 55 A3 00 FF, so you can compare two independent transmitters with one analysis method.

USART1 uses PCLK2. With the example’s nominal 16 MHz clock and oversampling by 16, BRR=139 approximates the requested baud. The resulting nominal rate is 16,000,000/139 ≈ 115108 baud, about 0.08% below 115200 before oscillator tolerance. Small divisor rounding is expected.

The transmit helper waits for TXE before writing DR. After the final byte, the program waits for TC before lowering the marker. TXE means the data register can accept more data; TC means the transmission has finished. Confusing those flags makes markers and half-duplex direction controls end too early.

NUCLEO-F411RE probe mapNUCLEO-F411REUSART1 · 3.3 V signalsKINGST LA1010INPUTS · passive probesD8 · PA9 TXCH0D10 · PB6 markerCH1GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
D8 · PA9 TXCH0
D10 · PB6 markerCH1
GNDGND
stm_uart_main.c
NUCLEO-F411RE · USART1 PA9/D8 TX · 115200 nominal
Read the complete program
#include "stm32f4xx.h"
#include <stdint.h>
// Empty STM32F411RE CMSIS project. No HAL_Init or HAL clock setup.
// Retain startup, linker script and exactly one SystemInit/SystemCoreClock source.
static void init16(void) {
  RCC->CR |= RCC_CR_HSION;
  while (!(RCC->CR & RCC_CR_HSIRDY)) {}
  RCC->CFGR &= ~RCC_CFGR_SW;   // select HSI before changing divisors
  while ((RCC->CFGR & RCC_CFGR_SWS)!=0u) {}
  RCC->CFGR = 0u;             // HCLK, PCLK1, PCLK2 = nominal 16 MHz
  SystemCoreClock = 16000000u;
  RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN | RCC_AHB1ENR_GPIOBEN;
  (void)RCC->AHB1ENR;
  CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
  DWT->CYCCNT=0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
}
static void us(uint32_t n) {
  uint32_t start=DWT->CYCCNT;
  while ((uint32_t)(DWT->CYCCNT-start)<n*16u) {}
}
static void output(GPIO_TypeDef *p,unsigned pin) {
  p->MODER=(p->MODER & ~(3u<<(pin*2))) | (1u<<(pin*2));
  p->OTYPER &= ~(1u<<pin);
  p->PUPDR &= ~(3u<<(pin*2));
}
static void af(GPIO_TypeDef *p,unsigned pin,unsigned f) {
  p->MODER=(p->MODER & ~(3u<<(pin*2))) | (2u<<(pin*2));
  p->OTYPER &= ~(1u<<pin);
  p->PUPDR &= ~(3u<<(pin*2));
  p->OSPEEDR=(p->OSPEEDR & ~(3u<<(pin*2))) | (2u<<(pin*2));
  unsigned shift=(pin%8u)*4u;
  p->AFR[pin/8u]=(p->AFR[pin/8u] & ~(15u<<shift)) | (f<<shift);
}

static void tx(uint8_t b) {
  while (!(USART1->SR & USART_SR_TXE)) {}
  USART1->DR=b;
}
int main(void) {
  init16(); af(GPIOA,9,7); output(GPIOB,6); // PB6/D10 marker
  GPIOB->BSRR=1u<<(6+16);
  RCC->APB2ENR |= RCC_APB2ENR_USART1EN; (void)RCC->APB2ENR;
  USART1->CR1=0; USART1->CR2=0; USART1->CR3=0;
  USART1->BRR=139u;          // round(16000000/115200), OVER8=0
  USART1->CR1=USART_CR1_UE | USART_CR1_TE; // 8N1
  while (1) {
    GPIOB->BSRR=1u<<6;
    tx(0x55); tx(0xA3); tx(0x00); tx(0xFF);
    while (!(USART1->SR & USART_SR_TC)) {}
    GPIOB->BSRR=1u<<(6+16);
    us(100000);
  }
}

At the bench · do this next

  1. Flash stm_uart_main.c and wire PA9/PB6/GND.
  2. Trigger on the marker and decode at 115200 8N1.
  3. Measure a bit period and compare it with the rounded-divisor prediction.

Pause & predict

Which flag should precede switching off a half-duplex transmitter after its final byte?
Reveal the reasoning

Transmission complete, TC, rather than merely TXE. The shift register may still be sending when TXE becomes true.

Reference trail: K2A5S2 · Expected waveforms are teaching predictions, not measured records.
Chapter 046

Discover an unknown baud rate

If the source settings are unknown, start by finding a region with frequent transitions. Measure several short intervals and look for a common bit-time unit. A plateau may span two, three or more bits, so treating the first width you see as one bit can give a false baud estimate.

A stream of 0x55 is particularly useful because alternating data produces nearly regular bit-spaced transitions. Measure across several intervals and divide to reduce cursor-placement error. Compare the inferred rate with plausible configured rates, then validate multiple asymmetric bytes and stop bits.

KingstVIS auto-baud can suggest a starting value, but confirmation comes from raw timing and consistent framing. If two settings decode a short repetitive capture plausibly, collect a richer known pattern. An ambiguity in the test signal is not something you fix by increasing confidence in the decoder.

At the bench · do this next

  1. Measure a set of narrow plateaus and infer a likely bit time.
  2. Convert using baud≈1/Tbit.
  3. Decode several different bytes and verify stop-bit alignment.

Pause & predict

A 17.36 µs plateau appears at 115200 baud. Does that imply 57600 baud?
Reveal the reasoning

Not necessarily. It may span two bit periods. Check other intervals and the full frame structure.

Reference trail: K2A5S2 · Expected waveforms are teaching predictions, not measured records.
Chapter 047

Make the decoder wrong on purpose

Keep the source at 115200 8N1, save the baseline and change only the analyzer baud to 9600. The waveform does not change, but the annotations should fail or become nonsense. This is a clean demonstration that decoding is an interpretation layer.

Restore the baud, then test inversion and parity mismatches one at a time. Record the symptom, then restore the known configuration. A mismatched decoder is safe because it does not drive the target, but it can still lead you to a false conclusion if you forget the setting.

Do not expect every wrong setting to create an error on every byte. Some patterns happen to resemble valid frames under more than one interpretation. Validate many bytes, especially asymmetric values and frame boundaries. A decoder reporting no errors is weaker evidence than it reproducing a deliberately known message.

At the bench · do this next

  1. Save a good raw capture.
  2. Change baud only, inspect, restore; then repeat with inversion.
  3. Explain which observations changed and which stayed identical.

Pause & predict

Can you repair this deliberate decoder fault without recapturing?
Reveal the reasoning

Yes, if the raw capture has adequate resolution and the needed interval. Change its interpretation settings back.

Reference trail: K2A5S2 · Expected waveforms are teaching predictions, not measured records.
Chapter 048

Add a local loopback response

For the UNO loopback lab, connect D1/TX to D0/RX through 1 kΩ with the board powered off. Remove any other device driving D0. Probe D1 on CH0, D0 on CH1 and D7 on CH2. The resistor limits accidental contention somewhat; it is not a voltage translator or universal protection device.

Upload the loopback sketch. Every 100 ms it sends 0xA3. On receiving that byte, it makes a 100 µs marker pulse. TX and RX should carry nearly the same serial waveform; the marker follows once the firmware reads the character. Its timing includes reception and loop scheduling.

This verifies the local transmit/receive path but not a remote peripheral protocol. A successful echo cannot prove that an external sensor accepts your command. It simply removes some uncertainty about the board UART and your analyzer setup. Disconnect loopback before attaching a real peer.

UNO R4 WiFi probe mapUNO R4 WiFiLocal UART loopback onlyKINGST LA1010INPUTS · passive probesD1 · TXCH0D0 · RXCH1D7 · received markerCH2GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
D1 · TXCH0
D0 · RXCH1
D7 · received markerCH2
GNDGND

Additional local loopback: D1 → 1 kΩ → D0. Remove every other driver from D0.

uno_echo.ino
UNO R4 WiFi · local UART loopback · D1 to D0 through 1 kΩ
Read the complete program
uint32_t last=0;
void setup() {
  pinMode(7, OUTPUT); digitalWrite(7, LOW);
  Serial1.begin(115200);
}
void loop() {
  if (uint32_t(millis()-last)>=100) {
    last=millis();
    Serial1.write(uint8_t(0xA3));
  }
  if (Serial1.available()) {
    uint8_t b=Serial1.read();
    if (b==0xA3) {
      digitalWrite(7, HIGH); delayMicroseconds(100);
      digitalWrite(7, LOW);
    }
  }
}

At the bench · do this next

  1. Wire the resistor loopback and three probes with power off.
  2. Capture at 10 MS/s, triggering on TX falling.
  3. Measure final stop region→marker response and repeat.

Pause & predict

Does this loopback require crossing voltage domains?
Reveal the reasoning

No. Both UART pins belong to the same UNO board domain. Do not extend this wiring directly to an STM32 or ESP input.

Reference trail: K2A5S2 · Expected waveforms are teaching predictions, not measured records.
Chapter 049

Separate framing errors from electrical standards

Logic-level UART, RS-232 and RS-485 can carry similar character framing while using very different electrical signaling. RS-232 uses a different voltage convention; RS-485 uses a differential pair and transceivers. A shared decoder menu is not a shared wiring diagram.

For learning, observe the logic-side TX/RX signals at a suitable transceiver or use a correctly designed receiver interface. Do not connect an analyzer ground to one conductor of a differential pair. Do not assume a 3.3 V MCU pin can tolerate an external serial connector because the payload is called UART.

In a real UART failure, work through idle level, bit width, frame format, direction, voltage compatibility and ground reference. If bytes fail only during motor switching, the protocol settings may be fine and the electrical environment may be the cause. The analyzer can locate the time of corruption; an oscilloscope may be needed to explain its voltage-level cause.

At the bench · do this next

  1. Identify whether a connector carries MCU logic, RS-232 or RS-485 before probing.
  2. Prefer the transceiver’s logic side for these bench lessons.
  3. Keep wiring standards and decoder format as separate notebook fields.

Pause & predict

Can a correctly selected UART decoder make an unsafe electrical connection safe?
Reveal the reasoning

No. Decoder settings only interpret acquired bits.

Reference trail: K2A5S2 · Expected waveforms are teaching predictions, not measured records.
Chapter 050

UART checkpoint: prove an entire exchange

Capture a complete known message with its marker. Your report should state idle polarity, measured bit period, format, byte order, number of frames and total burst duration. Show one manually decoded asymmetric byte and explain why equal-bit plateaus have different widths.

For a more realistic exchange, define request start, request completion and response start separately. A “response time” measured from the first request bit includes the request transmission itself. Measuring from the final stop bit answers a different question. Both can be useful if clearly named.

As a challenge, double the source baud and adjust only the settings that must change. Keep the sample rate sufficient for the shorter bits. Predict the burst duration approximately halves, while a fixed 100 ms delay between bursts remains a fixed delay. Save both records and compare the same event definitions.

At the bench · do this next

  1. Produce a capture contract plus manual decode for one frame.
  2. Name the start and end events of each timing measurement.
  3. Repeat with a new known baud and explain the changed durations.

Pause & predict

What if the bytes decode correctly but only half the burst is visible?
Reveal the reasoning

The capture is incomplete. Increase the time window or change the trigger position; correct labels do not prove a complete transaction.

Reference trail: K2A5S2 · Expected waveforms are teaching predictions, not measured records.
Section 06 · Chapters 051–060

I²C: two wires, shared responsibility

Pull-ups, START, ACK, and the useful NACK

You will first observe a deliberately absent target. A NACK is then a correct predicted outcome, not a mysterious failure. Later, add a known compatible peripheral and interpret its protocol.

051 Why I²C releases a wire to make it HIGH 052 START and STOP give the clock a context 053 Address bits are not the whole address byte 054 The ninth clock asks “did you hear me?” 055 UNO lab: make a predictable NACK 056 Qwiic is a separate bus, not another A4 socket 057 STM32 lab: expose every I²C edge in C 058 Read a real register transaction 059 Pull-up strength and clock stretching 060 I²C checkpoint: diagnose in a fixed order
Chapter 051

Why I²C releases a wire to make it HIGH

I²C uses a clock line, SCL, and a data line, SDA. Ordinary devices pull these lines LOW or release them; pull-up resistors restore HIGH. This lets multiple participants share a line without one actively driving HIGH against another pulling LOW.

A missing pull-up can leave a released line floating. A pull-up to the wrong rail can overvoltage a device. A module advertised as “5 V powered” may still use 3.3 V data pins, so inspect its schematic or electrical specification. Power input tolerance does not automatically describe SDA/SCL tolerance.

For the no-target UNO header experiment, use one 4.7 kΩ resistor from A4/SDA to 5 V and one from A5/SCL to 5 V. For the STM32 experiment, use pull-ups to 3.3 V on PB9/PB8. Never connect these two separately pulled-up buses directly together. These are independent experiments with one board at a time.

I²C pull-up and probe connectionsUNO R4 WiFi · no-target I²C benchCONTROLLERLA10105 V pull-up railA4 / SDACH04.7 kΩA5 / SCLCH14.7 kΩGNDGND
No target is attached: address NACK is expected. Power off before wiring. Use only the rail stated for the selected board.

At the bench · do this next

  1. With power off, install the two pull-ups for the chosen board only.
  2. Probe SDA, SCL and common GND.
  3. Power up and confirm both lines idle HIGH before starting a transaction.

Pause & predict

Does writing HIGH to an open-drain output mean it actively supplies the HIGH voltage?
Reveal the reasoning

No. It releases the line; the pull-up provides the HIGH level.

Reference trail: N1K2A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 052

START and STOP give the clock a context

During ordinary I²C data bits, SDA stays stable while SCL is HIGH and changes while SCL is LOW. START is a special transition: SDA falls while SCL is HIGH. STOP is SDA rising while SCL is HIGH. Those exceptions frame the conversation.

A repeated START begins a new addressed phase without releasing the bus through a STOP. Register reads often use a write phase to select a register, then a repeated START for a read phase. The exact transaction required belongs to the target’s datasheet, not a generic assumption about all sensors.

When decoding fails, inspect these structural events before worrying about payload values. Swapped SDA/SCL assignments can generate bizarre annotations. A capture that starts in the middle of a transaction may lack the context needed to interpret the first bits. Include some idle time or trigger on a recognizable START condition.

I²C START and STOPI²C START and STOPSDASCL
Conceptual sequence: START is SDA falling with SCL HIGH; STOP is SDA rising with SCL HIGH.

At the bench · do this next

  1. Find idle HIGH/HIGH in a trace.
  2. Locate SDA falling while SCL stays HIGH.
  3. Find the STOP after the addressed phase.

Pause & predict

Is every falling edge on SDA a START?
Reveal the reasoning

No. It is START only when SCL is HIGH. During SCL LOW it can be an ordinary data change.

Reference trail: N1K2A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 053

Address bits are not the whole address byte

In common 7-bit I²C addressing, the first transmitted byte combines seven address bits and one direction bit. Address 0x48 with write direction produces raw byte 0x90; with read direction it produces 0x91. The expression is (address<<1)|R/W.

Arduino Wire APIs normally expect the 7-bit address, so pass 0x48 for this example rather than the on-wire 0x90. A datasheet that prints both read and write “addresses” may be showing the eight-bit forms. Check its convention before copying a number.

KingstVIS offers address-display choices. Choose seven-bit display for this guide and write the selected convention in your notes. If one screenshot says 0x48 and another says 0x90, they may describe the same write transaction rather than disagreeing about the device. Read the direction annotation as well as the number.

I²C START and STOPI²C START and STOPSDASCL
Conceptual sequence: START is SDA falling with SCL HIGH; STOP is SDA rising with SCL HIGH.

At the bench · do this next

  1. Set the analyzer’s address display to seven-bit.
  2. Calculate raw write/read bytes for address 0x48.
  3. Compare the first eight raw bits with the decoded address and direction.

Pause & predict

What raw first byte represents a read from seven-bit address 0x3C?
Reveal the reasoning

(0x3C<<1)|1 = 0x79.

Reference trail: N1K2A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 054

The ninth clock asks “did you hear me?”

After eight bits, the transmitter releases SDA for an acknowledgment bit. The receiver pulls SDA LOW for ACK or leaves it HIGH for NACK. This ninth clock belongs to the handshake, not to an extra payload bit.

Ownership changes with direction. After an address, an addressed target normally acknowledges. During a controller write, the target acknowledges received data. During a controller read, the controller acknowledges additional desired bytes and typically NACKs the final byte before ending the transfer. Thus a final read NACK can be the normal planned ending.

An address NACK has several possible causes: no target, wrong address, target asleep, missing power, or electrical problems. The bits tell you that acknowledgment was not observed; they do not identify the cause automatically. Our next lab deliberately omits the target so you can recognize a clean, expected address NACK.

I²C acknowledgment ownershipEight bits, then a ninth clock for acknowledgmentb7b6b5b4b3b2b1b0ACK?Transmitter owns SDA for eight bits.Receiver owns the ninth bit: LOW = ACK; released HIGH = NACK.
During a read, the controller is the receiver for data bytes. A final read NACK can be normal.

At the bench · do this next

  1. Count eight address/direction clocks and the ninth acknowledgment clock.
  2. Read SDA during the ninth HIGH interval.
  3. Distinguish address NACK from final-data NACK in your notes.

Pause & predict

Is every NACK an error?
Reveal the reasoning

No. An absent-target probe expects one, and a controller normally uses a final NACK to end many read transfers.

Reference trail: N1K2A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 055

UNO lab: make a predictable NACK

Use the UNO’s ordinary Wire bus: A4/SDA and A5/SCL, also available at their duplicated SDA/SCL header positions. Fit the two 4.7 kΩ pull-ups to 5 V with no target attached. Connect CH0 to SDA, CH1 to SCL and optionally CH2 to D7.

Upload the address-only probe. It requests 100 kHz SCL and sends address 0x48 with write direction every 100 ms. There is no register or data write. Expect START, eight address/direction bits corresponding to 0x90, a ninth HIGH SDA NACK bit, and STOP. A NACK here is the success criterion.

Set 10 MS/s, 2.5 V threshold and a roughly 10 ms record. Trigger on the D7 rising marker if used, or initially capture freely. Add the I²C analyzer with SDA=CH0 and SCL=CH1. The software’s status variable can support the observation, but the capture lets you verify what occurred electrically.

I²C pull-up and probe connectionsUNO R4 WiFi · no-target I²C benchCONTROLLERLA10105 V pull-up railA4 / SDACH04.7 kΩA5 / SCLCH14.7 kΩGNDGND
No target is attached: address NACK is expected. Power off before wiring. Use only the rail stated for the selected board.
uno_i2c_probe.ino
UNO R4 WiFi · safe address-only I²C probe · A4/A5
Read the complete program
#include <Wire.h>
const uint8_t address=0x48; // No target required: NACK is expected.
volatile uint8_t lastStatus=255;
void setup() {
  pinMode(7, OUTPUT); digitalWrite(7, LOW);
  Wire.begin(); Wire.setClock(100000);
}
void loop() {
  digitalWrite(7, HIGH);
  Wire.beginTransmission(address);
  lastStatus=Wire.endTransmission(); // no register writes
  digitalWrite(7, LOW);
  delay(100);
}

At the bench · do this next

  1. Wire pull-ups and probes with power off; leave targets disconnected.
  2. Upload uno_i2c_probe.ino.
  3. Decode seven-bit address 0x48, write, NACK; count nine clocks.

Pause & predict

Why not start with a scan of every address?
Reveal the reasoning

A single known transaction is easier to interpret and avoids interrogating unrelated devices. Start with a controlled question.

Reference trail: N1K2A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 056

Qwiic is a separate bus, not another A4 socket

The UNO R4 WiFi’s Qwiic connector belongs to the 3.3 V I²C interface exposed by Wire1. The ordinary SDA/SCL headers use Wire. Probing one while programming the other produces a perfectly explainable flat trace.

For a Qwiic variant, use a proper breakout cable and a 3.3 V compatible device or explicit pull-ups to the 3.3 V rail. Replace each Wire call in the address-only sketch with Wire1, and use a suitable threshold such as 1.5 V. Confirm connector orientation and pin names from the official pinout; do not infer order from wire colors alone.

If a module already contains pull-ups, account for them before adding more. Parallel pull-ups reduce the effective resistance. The analyzer is an observer, not the bus pull-up source. Capture the idle state, address phase and ACK/NACK as before. Compare only equivalent conditions when judging one bus against the other.

At the bench · do this next

  1. Identify the Qwiic SDA, SCL, 3.3 V and GND via a breakout.
  2. Use Wire1 consistently and a 3.3 V threshold plan.
  3. Capture the same single-address experiment and document existing pull-ups.

Pause & predict

The Qwiic device is quiet while A4/A5 show clocks. What should you inspect first?
Reveal the reasoning

Which Wire object the sketch uses. Wire and Wire1 select different physical buses.

Reference trail: N1K2A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 057

STM32 lab: expose every I²C edge in C

The STM32 teaching program deliberately generates an address-only transaction with open-drain GPIO on PB8/SCL and PB9/SDA. Use the dedicated D15/SCL and D14/SDA header positions, pull each line to 3.3 V through 4.7 kΩ, and attach no target for the first run.

This is a bit-banged observation exercise, not a complete production I²C driver. It makes START, bit placement, clock release, acknowledgment sampling and STOP visible in short C functions. It waits for SCL to rise with a bounded timeout, but does not implement arbitration or full bus recovery. Software overhead makes the clock slower than an ideal 100 kHz calculation from two 5 µs delays.

Set CH0=SDA, CH1=SCL, 1.5 V threshold and 10 MS/s. Expect address 0x48 write and NACK. Then trace one bit back through the code. The peripheral I2C1 can automate these phases, but the wire-level meaning stays the same; that is the concept you need before debugging a hardware driver.

I²C pull-up and probe connectionsNUCLEO-F411RE · no-target I²C benchCONTROLLERLA10103.3 V pull-up railPB9 / D14CH04.7 kΩPB8 / D15CH14.7 kΩGNDGND
No target is attached: address NACK is expected. Power off before wiring. Use only the rail stated for the selected board.
stm_i2c_observe_main.c
NUCLEO-F411RE · teaching I²C bit-bang · PB8 SCL/PB9 SDA · no target required
Read the complete program
#include "stm32f4xx.h"
#include <stdint.h>
// Empty STM32F411RE CMSIS project. No HAL_Init or HAL clock setup.
// Retain startup, linker script and exactly one SystemInit/SystemCoreClock source.
static void init16(void) {
  RCC->CR |= RCC_CR_HSION;
  while (!(RCC->CR & RCC_CR_HSIRDY)) {}
  RCC->CFGR &= ~RCC_CFGR_SW;   // select HSI before changing divisors
  while ((RCC->CFGR & RCC_CFGR_SWS)!=0u) {}
  RCC->CFGR = 0u;             // HCLK, PCLK1, PCLK2 = nominal 16 MHz
  SystemCoreClock = 16000000u;
  RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN | RCC_AHB1ENR_GPIOBEN;
  (void)RCC->AHB1ENR;
  CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
  DWT->CYCCNT=0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
}
static void us(uint32_t n) {
  uint32_t start=DWT->CYCCNT;
  while ((uint32_t)(DWT->CYCCNT-start)<n*16u) {}
}
static void output(GPIO_TypeDef *p,unsigned pin) {
  p->MODER=(p->MODER & ~(3u<<(pin*2))) | (1u<<(pin*2));
  p->OTYPER &= ~(1u<<pin);
  p->PUPDR &= ~(3u<<(pin*2));
}
static void af(GPIO_TypeDef *p,unsigned pin,unsigned f) {
  p->MODER=(p->MODER & ~(3u<<(pin*2))) | (2u<<(pin*2));
  p->OTYPER &= ~(1u<<pin);
  p->PUPDR &= ~(3u<<(pin*2));
  p->OSPEEDR=(p->OSPEEDR & ~(3u<<(pin*2))) | (2u<<(pin*2));
  unsigned shift=(pin%8u)*4u;
  p->AFR[pin/8u]=(p->AFR[pin/8u] & ~(15u<<shift)) | (f<<shift);
}

// Educational single-controller ADDRESS-ONLY probe, not a general I2C driver.
// External 4.7k pull-ups to 3.3V on both lines are required.
// Handles bounded clock-stretch wait; no arbitration or bus recovery.
#define SCL (1u<<8)
#define SDA (1u<<9)
static void low(uint32_t m) { GPIOB->BSRR=m<<16; }
static void release(uint32_t m) { GPIOB->BSRR=m; }
static int clock_high(void) {
  release(SCL);
  uint32_t t=DWT->CYCCNT;
  while (!(GPIOB->IDR&SCL)) {
    if ((uint32_t)(DWT->CYCCNT-t)>16000u) return 0; // 1 ms timeout
  }
  us(5); return 1;
}
static int probe(uint8_t address) {
  release(SDA|SCL); us(10);
  if ((GPIOB->IDR&(SCL|SDA))!=(SCL|SDA)) return -1;
  low(SDA); us(5); low(SCL); // START
  uint8_t b=address<<1;
  for (unsigned i=0;i<8;i++) {
    if (b&0x80) release(SDA); else low(SDA);
    us(5); if (!clock_high()) goto failed;
    low(SCL); b<<=1;
  }
  release(SDA); us(5);
  if (!clock_high()) goto failed;
  int ack=(GPIOB->IDR&SDA)==0;
  low(SCL); low(SDA); us(5);
  if (!clock_high()) goto failed;
  release(SDA); us(5); // STOP
  return ack;
failed:
  release(SDA|SCL); return -1;
}
volatile int result;
int main(void) {
  init16();
  GPIOB->BSRR=SCL|SDA;       // preload released state before enabling output
  output(GPIOB,8); output(GPIOB,9);
  GPIOB->OTYPER |= SCL|SDA; // open drain: HIGH releases, never drives high
  while (1) { result=probe(0x48); us(100000); }
}

At the bench · do this next

  1. Flash stm_i2c_observe_main.c and connect the 3.3 V pull-ups.
  2. Capture freely, then add the I²C decoder.
  3. Explain why a returned result of zero is expected without a target.

Pause & predict

Does this program prove that the STM32 I2C1 peripheral was configured correctly?
Reveal the reasoning

No. It uses GPIO bit-banging. It teaches bus behavior; hardware I2C1 configuration is a separate task.

Reference trail: N1K2A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 058

Read a real register transaction

Once the no-target baseline works, choose a documented compatible peripheral and read its address, voltage requirements and register-read sequence. Do not assume every device uses an eight-bit register index or supports a repeated START in the same way.

A common pattern is START, address+write, ACK, register index, ACK, repeated START, address+read, ACK, data, controller NACK, STOP. Label who drives each phase. The target may require a command, conversion delay or additional bytes before a useful reading is available.

Capture the full sequence with both SDA and SCL. If the register-index byte is correct but the returned value is wrong, investigate initialization, byte order, signedness and timing in the target documentation. The analyzer can show the exact bytes exchanged but does not know whether you chose the right physical quantity or conversion formula. Keep target-specific code separate from the generic no-target checkpoint.

I²C register-read phasesA common single-register read patternSTARTAddr + WACKRegisterACKRESTARTAddr + RACKDataNACKSTOPVerify the actual target’s required sequence; this pattern is not universal.
Controller NACK after the final received byte ends the planned read; it is not automatically a fault.

At the bench · do this next

  1. Choose one register with a documented fixed ID or reset value.
  2. Write the expected transaction before executing it.
  3. Capture and compare address, index, direction, ACK ownership and returned bytes.

Pause & predict

Why is a device-ID register often a better first test than a changing sensor value?
Reveal the reasoning

A known fixed value makes address, register selection and byte interpretation easier to verify.

Reference trail: N1K2A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 059

Pull-up strength and clock stretching

Pull-ups and bus capacitance shape rising edges. A larger resistance reduces LOW-state current but slows the rise; a smaller resistance speeds the rise but asks devices to sink more current. A useful first-order rise-time estimate between 30% and 70% is tr≈0.8473RC. Check the I²C specification and every device’s sink capability before choosing values.

The logic analyzer shows only threshold-crossing times, so it cannot certify analog rise time from a clean digital trace. Unexpected short HIGH periods or threshold-sensitive decoding may motivate an oscilloscope measurement. Long jumpers and multiple modules add capacitance; several onboard pull-ups in parallel change resistance.

Clock stretching occurs when a target holds SCL LOW after the controller releases it. The actual bus clock then differs from the controller’s nominal setting. A longer LOW interval can therefore be legitimate, but a line stuck LOW indefinitely needs investigation. Distinguish permitted stretching, a powered-off device clamping the bus and a wiring short.

At the bench · do this next

  1. Measure actual SCL HIGH and LOW durations.
  2. Inspect module pull-up values and their rail connections.
  3. Use an oscilloscope if rise time or voltage margin is the unresolved question.

Pause & predict

Can the analyzer distinguish a 200 ns analog rise from a 900 ns rise solely from an idealized square trace?
Reveal the reasoning

No. It records crossing decisions at its threshold, not the full analog edge shape.

Reference trail: N1K2A2A5 · Expected waveforms are teaching predictions, not measured records.
Chapter 060

I²C checkpoint: diagnose in a fixed order

Use a disciplined sequence: supply and ground, idle levels, START, clock activity, address bits, acknowledgment, payload, STOP. This order prevents you from debugging register interpretation while the bus is electrically stuck LOW.

For a controlled fault, keep the no-target lab intact but swap SDA and SCL only in the analyzer configuration. Observe the decoder failure, then restore the mapping without touching the hardware. Next compare seven-bit and eight-bit address display modes. These exercises show how software settings can produce apparent faults while the electrical capture stays unchanged.

For a real target, save one good identity-register read before trying complex commands. If a later transaction fails, compare the first point where its raw waveform diverges from the baseline. A useful report says “address ACK present, register byte ACK present, read address NACK” rather than “I²C is broken.”

At the bench · do this next

  1. Reproduce the clean NACK experiment from notes.
  2. Perform and restore the decoder-only mapping fault.
  3. Write a diagnosis that names the exact failed bus phase.

Pause & predict

If SDA is permanently LOW before START, should you first change the address?
Reveal the reasoning

No. Resolve the electrical or bus-state problem first. Address interpretation requires a functioning transaction.

Reference trail: N1K2A2A5 · Expected waveforms are teaching predictions, not measured records.
Section 07 · Chapters 061–070

SPI: the clock is part of the message

Four wires, four modes, one controlled loopback

Use known asymmetric bytes before connecting a display or sensor. SPI is easy to make look busy and surprisingly easy to decode incorrectly.

061 Name signals by direction and ownership 062 CPOL and CPHA answer two separate questions 063 UNO loopback: a peripheral made from one resistor 064 Configure the SPI decoder precisely 065 Read 0x96 on the sampling edges 066 STM32 SPI1: follow the route from APB2 067 Find a mode mismatch without guessing 068 Chip select is part of the protocol 069 Probe a real sensor or display thoughtfully 070 SPI checkpoint: build a protocol argument
Chapter 061

Name signals by direction and ownership

SPI commonly uses SCK, controller-out/peripheral-in data, peripheral-out/controller-in data and chip select. KingstVIS uses the familiar MOSI and MISO labels; Arduino documentation also uses COPI and CIPO. The names describe the same direction relative to the controller.

The controller supplies the clock and normally selects a peripheral with an active-LOW CS line. Each clock can shift a bit in both directions, even when the application cares about only one. Reading a sensor often requires transmitting dummy bytes to generate clocks.

SPI has no universal address byte, acknowledgment bit or packet meaning. Each peripheral defines its own command structure and CS timing. A valid-looking sequence of bytes therefore proves only that a chosen interpretation fits the wires. To prove a device operation, compare the waveform with that device’s protocol and a known expected result.

Measurement concept mapSPI is a conversation with a clockSCKMOSI / COPIMISO / CIPOCS / ENABLE
Original teaching illustration. All waveform examples in the guide are illustrative unless explicitly described as your own capture.

At the bench · do this next

  1. Write SCK, MOSI/COPI, MISO/CIPO and CS in your channel map.
  2. Identify which participant drives each line.
  3. Reserve a fourth channel for CS even when a three-wire view seems tempting.

Pause & predict

Does SPI define a universal ACK after every byte?
Reveal the reasoning

No. Any status or response meaning comes from the particular peripheral’s protocol.

Reference trail: K2A7S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 062

CPOL and CPHA answer two separate questions

CPOL defines the idle clock level. CPHA defines whether sampling occurs on the first or second clock edge within a bit period. “First edge” means the transition away from idle, so its rising/falling identity depends on CPOL.

Mode 0 is CPOL=0, CPHA=0: idle LOW, sample on rising edges. Mode 1 is idle LOW, sample on falling edges. Mode 2 is idle HIGH, sample on falling edges. Mode 3 is idle HIGH, sample on rising edges. Learn the relationship instead of memorizing only a mode number.

The transmitter must make data stable around the receiver’s sampling edge. Mode 0 prepares the first data bit before the first rising edge. Other modes may shift it at a different phase. Use the mode explorer and verify a byte manually; a decoder menu that says “first edge” is describing a relationship, not always a rising edge.

SPI mode explorer · 0x96, MSB first

Dots mark sampling edges. Ideal timing; not a setup/hold measurement.

At the bench · do this next

  1. Set the mode explorer to all four modes.
  2. Identify idle level and sampling edge in each.
  3. Write the required mode beside your source configuration.

Pause & predict

Which two modes sample on rising edges?
Reveal the reasoning

Modes 0 and 3. Their idle levels and phase relationships differ.

Reference trail: K2A7S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 063

UNO loopback: a peripheral made from one resistor

Power off and connect D11/COPI to D12/CIPO through 1 kΩ. Remove any external SPI peripheral first. Connect CH0 to D13/SCK, CH1 to D11/COPI, CH2 to D12/CIPO and CH3 to D10/CS. Connect GND. The resistor links a controller output to a controller input within the same voltage domain.

Upload the SPI loopback sketch. It sends 0x96, 0x3C and 0xA5 at a requested 1 MHz, MSB first, mode 0, with CS LOW across the three-byte burst. The received array should match because the outgoing bits return through the loopback wire.

Four enabled channels cap the LA1010 at 50 MS/s. Choose 50 MS/s for the initial detailed capture and a window of a few milliseconds triggered on CS falling. With 24 clocks, the active clocking lasts about 24 µs plus software gaps. This is a loopback verification, not an imitation of a real sensor’s command parser.

UNO R4 WiFi probe mapUNO R4 WiFiSPI · 5 V header signalsKINGST LA1010INPUTS · passive probesD13 · SCKCH0D11 · COPI/MOSICH1D12 · CIPO/MISOCH2D10 · CSCH3GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
D13 · SCKCH0
D11 · COPI/MOSICH1
D12 · CIPO/MISOCH2
D10 · CSCH3
GNDGND

Additional local loopback: D11 → 1 kΩ → D12. Remove all external SPI devices. Do not join power rails.

uno_spi_loopback.ino
UNO R4 WiFi · SPI mode 0 · D11 to D12 through 1 kΩ
Read the complete program
#include <SPI.h>
volatile uint8_t received[3];
void setup() {
  pinMode(10, OUTPUT); digitalWrite(10, HIGH);
  SPI.begin();
}
void loop() {
  const uint8_t bytes[]={0x96,0x3C,0xA5};
  SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));
  digitalWrite(10, LOW);
  for (unsigned i=0;i<3;i++) received[i]=SPI.transfer(bytes[i]);
  digitalWrite(10, HIGH);
  SPI.endTransaction();
  delay(100);
}

At the bench · do this next

  1. Wire the local resistor loopback and four probes.
  2. Upload uno_spi_loopback.ino.
  3. Capture CS falling at 50 MS/s and inspect 24 clock cycles.

Pause & predict

Why remove an attached peripheral before connecting loopback?
Reveal the reasoning

Its MISO output could drive against MOSI through the loopback path. Use only the isolated local experiment.

Reference trail: K2A7S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 064

Configure the SPI decoder precisely

Add SPI in KingstVIS. For the UNO wiring above, assign CLOCK=CH0, MOSI=CH1, MISO=CH2 and ENABLE=CH3. Choose eight-bit words, MSB first, CPOL=0, CPHA=0 and active-LOW enable. Keep the source’s mode and the analyzer’s mode in agreement.

Expect the same 96 3C A5 values in each direction for loopback. If MISO reads all ones or zeros while MOSI is correct, check the loopback wire and pin assignment. If both streams decode oddly, inspect clock polarity, phase, word length and CS framing.

The ENABLE assignment matters. It marks where the selected peripheral considers a transaction valid. Without it, a decoder may group clocks across unrelated bursts and show misleading byte boundaries. A three-channel capture can be useful for a narrowly defined question, but it should not be your default when transaction framing matters.

At the bench · do this next

  1. Enter all four channel assignments explicitly.
  2. Set 8 bits, MSB first, mode 0 and active-LOW enable.
  3. Inspect raw edges beneath one MOSI and MISO annotation.

Pause & predict

What should the loopback MISO payload be?
Reveal the reasoning

96 3C A5, matching the transmitted stream, assuming the wiring and input sampling are correct.

Reference trail: K2A7S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 065

Read 0x96 on the sampling edges

0x96 is binary 10010110. With MSB-first transfer, that is also its left-to-right time order. In mode 0, mark the eight rising SCK edges while CS is LOW and read MOSI at each. The sum of weights 128+16+4+2 gives 150 decimal, or 0x96.

Use a byte such as 0x96 because reversing its bit order gives 0x69. Symmetric patterns can hide bit-order errors. Check the first and last bit carefully: a wrong phase often shows up at burst boundaries even when some interior data appears plausible.

The analyzer samples asynchronously relative to SCK. At 50 MS/s and 1 MHz, you have nominally 50 samples per clock period, providing comfortable inspection resolution for this teaching signal. That does not certify high-speed electrical margins at a real receiver. For setup/hold limits near a few nanoseconds, a different measurement instrument may be required.

SPI mode explorer · 0x96, MSB first

Dots mark sampling edges. Ideal timing; not a setup/hold measurement.

At the bench · do this next

  1. Mark eight rising clocks inside the first selected byte.
  2. Read MOSI at those edges and calculate the value.
  3. Repeat at the next byte without relying on its annotation.

Pause & predict

Why is 0xA5 a weaker bit-order test than 0x96?
Reveal the reasoning

0xA5 reverses to itself. 0x96 reverses to 0x69, exposing the mistake more clearly.

Reference trail: K2A7S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 066

STM32 SPI1: follow the route from APB2

Flash the SPI1 checkpoint. It routes SCK to PA5/D13, MISO to PA6/D12 and MOSI to PA7/D11, using AF5. PB6/D10 is software-controlled CS. Connect PA7/D11 to PA6/D12 through 1 kΩ for local loopback, with no external device attached.

The example’s PCLK2 is nominally 16 MHz. SPI baud divider /16 gives 1 MHz. CR1 selects controller mode, software management of NSS and an internally high NSS state, avoiding an unintended mode fault. CPOL and CPHA are zero; eight-bit transfers and MSB-first are selected by their reset-valued fields.

The code reads each received byte and waits for BSY to clear before raising CS at burst end. Waiting only for TXE is insufficient because the final bits may still be on the wire. Probe with the same four-channel arrangement as the UNO, but use a 1.5 V threshold. Expect the same 96 3C A5 payload.

NUCLEO-F411RE probe mapNUCLEO-F411RESPI1 · 3.3 V signalsKINGST LA1010INPUTS · passive probesD13 · PA5 SCKCH0D11 · PA7 MOSICH1D12 · PA6 MISOCH2D10 · PB6 CSCH3GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
D13 · PA5 SCKCH0
D11 · PA7 MOSICH1
D12 · PA6 MISOCH2
D10 · PB6 CSCH3
GNDGND

Additional local loopback: PA7/D11 → 1 kΩ → PA6/D12. Remove all external SPI devices.

stm_spi_main.c
NUCLEO-F411RE · SPI1 PA5/6/7 · PB6/D10 CS
Read the complete program
#include "stm32f4xx.h"
#include <stdint.h>
// Empty STM32F411RE CMSIS project. No HAL_Init or HAL clock setup.
// Retain startup, linker script and exactly one SystemInit/SystemCoreClock source.
static void init16(void) {
  RCC->CR |= RCC_CR_HSION;
  while (!(RCC->CR & RCC_CR_HSIRDY)) {}
  RCC->CFGR &= ~RCC_CFGR_SW;   // select HSI before changing divisors
  while ((RCC->CFGR & RCC_CFGR_SWS)!=0u) {}
  RCC->CFGR = 0u;             // HCLK, PCLK1, PCLK2 = nominal 16 MHz
  SystemCoreClock = 16000000u;
  RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN | RCC_AHB1ENR_GPIOBEN;
  (void)RCC->AHB1ENR;
  CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
  DWT->CYCCNT=0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
}
static void us(uint32_t n) {
  uint32_t start=DWT->CYCCNT;
  while ((uint32_t)(DWT->CYCCNT-start)<n*16u) {}
}
static void output(GPIO_TypeDef *p,unsigned pin) {
  p->MODER=(p->MODER & ~(3u<<(pin*2))) | (1u<<(pin*2));
  p->OTYPER &= ~(1u<<pin);
  p->PUPDR &= ~(3u<<(pin*2));
}
static void af(GPIO_TypeDef *p,unsigned pin,unsigned f) {
  p->MODER=(p->MODER & ~(3u<<(pin*2))) | (2u<<(pin*2));
  p->OTYPER &= ~(1u<<pin);
  p->PUPDR &= ~(3u<<(pin*2));
  p->OSPEEDR=(p->OSPEEDR & ~(3u<<(pin*2))) | (2u<<(pin*2));
  unsigned shift=(pin%8u)*4u;
  p->AFR[pin/8u]=(p->AFR[pin/8u] & ~(15u<<shift)) | (f<<shift);
}

volatile uint8_t received[3];
static uint8_t transfer(uint8_t b) {
  while (!(SPI1->SR & SPI_SR_TXE)) {}
  *(__IO uint8_t *)&SPI1->DR=b;
  while (!(SPI1->SR & SPI_SR_RXNE)) {}
  return *(__IO uint8_t *)&SPI1->DR;
}
int main(void) {
  init16();
  af(GPIOA,5,5); af(GPIOA,6,5); af(GPIOA,7,5);
  output(GPIOB,6); GPIOB->BSRR=1u<<6;
  RCC->APB2ENR |= RCC_APB2ENR_SPI1EN; (void)RCC->APB2ENR;
  SPI1->CR1=0; SPI1->CR2=0;
  // PCLK2/16 = 1 MHz; master, software NSS high, mode 0, 8-bit MSB.
  SPI1->CR1=SPI_CR1_MSTR | (3u<<3) | SPI_CR1_SSM | SPI_CR1_SSI;
  SPI1->CR1 |= SPI_CR1_SPE;
  while (1) {
    GPIOB->BSRR=1u<<(6+16);
    received[0]=transfer(0x96); received[1]=transfer(0x3C);
    received[2]=transfer(0xA5);
    while (SPI1->SR & SPI_SR_BSY) {}
    GPIOB->BSRR=1u<<6;
    us(100000);
  }
}

At the bench · do this next

  1. Flash stm_spi_main.c and wire local PA7→1 kΩ→PA6 loopback.
  2. Map CH0=SCK, CH1=MOSI, CH2=MISO, CH3=PB6 CS.
  3. Capture at 50 MS/s with mode-0 decoding.

Pause & predict

Why wait for BSY before ending CS?
Reveal the reasoning

The transmit data register may be empty before the final clocked transfer has finished. CS must cover the whole selected transaction.

Reference trail: K2A7S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 067

Find a mode mismatch without guessing

Save a good loopback capture, then change only the decoder’s CPHA. Watch which bytes change and where the sample markers fall relative to data transitions. Restore it before changing CPOL. This isolates interpretation errors from source errors.

A wrong mode may still decode some bytes correctly when data happens to be stable at both candidate edges. Do not choose a mode solely because the result looks readable. The peripheral’s datasheet defines its sampling requirements, and the raw capture should agree with those requirements.

For a real mismatch between controller and peripheral, compare data-valid intervals around the required sampling edges. If the controller shifts on the same edge that the peripheral samples, timing margin can collapse. Low clock rates sometimes mask the problem, which explains why a design may work slowly and fail after a speed increase.

At the bench · do this next

  1. Compare correct and incorrect decoder modes on the same raw capture.
  2. Use asymmetric bytes and burst boundaries to inspect the difference.
  3. Restore the mode specified by the source and target documentation.

Pause & predict

If two decoder modes show the same byte, are they both necessarily valid for the target?
Reveal the reasoning

No. The target samples according to its own required mode; stable test data can conceal a mismatch.

Reference trail: K2A7S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 068

Chip select is part of the protocol

Many SPI peripherals interpret CS edges as transaction boundaries. Raising CS between a command and its data can cancel an operation; keeping it LOW across commands that require separate transactions can also be wrong. There is no universal rule beyond the target’s protocol.

Measure CS-to-first-clock setup, final-clock-to-CS hold, and spacing between transactions. Choose marker definitions based on the relevant first or last active clock edge. If the target requires a minimum CS HIGH time, a correct byte stream alone cannot prove compliance.

As a controlled loopback exercise, move the software CS HIGH/LOW pair inside the byte loop. The bytes can still echo correctly, yet the transaction grouping changes from one three-byte burst to three one-byte bursts. This demonstrates why a loopback test verifies the serial path but cannot certify a real peripheral command sequence.

CS groups clocks into a transactionCS groups clocks into a transactionCSSCK
Conceptual excerpt. Real examples contain 24 clocks; selection setup and hold are target-specific.

At the bench · do this next

  1. Measure CS setup and hold on the baseline.
  2. Experiment with per-byte CS only in the isolated loopback lab.
  3. Explain how the transaction grouping changed despite identical payload bytes.

Pause & predict

Can a device reject perfectly decoded bytes because of CS timing?
Reveal the reasoning

Yes. Selection boundaries and timing are part of its protocol.

Reference trail: K2A7S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 069

Probe a real sensor or display thoughtfully

Start with the target’s voltage limits, pin definitions, required mode, maximum clock and transaction diagram. Connect the analyzer in parallel with the existing signals; it does not replace the peripheral. Begin at a conservative clock rate supported by the target.

For a sensor, a fixed identity register is a useful first transaction. For a display, a command/data pin or reset pin may matter as much as MOSI. Add those channels and recalculate the LA1010’s maximum sample rate. More context can be more valuable than the highest rate, provided resolution remains sufficient.

Compare command bytes, dummy cycles, read length, CS grouping and response order. Some devices return data one byte or one transaction later. A line full of 0xFF may mean an undriven input, but it may also be a legitimate response. Test the physical connection and the protocol expectation before drawing a conclusion.

At the bench · do this next

  1. Write the peripheral’s required mode and transaction structure.
  2. Capture reset or command/data along with SPI if needed.
  3. Compare one documented simple operation before sending a long frame.

Pause & predict

Why might a display need five or six analyzer channels rather than four?
Reveal the reasoning

Command/data and reset timing can explain how the same SPI bytes are interpreted.

Reference trail: K2A7S2S3 · Expected waveforms are teaching predictions, not measured records.
Chapter 070

SPI checkpoint: build a protocol argument

Your checkpoint report should contain the pin map, voltage domain, clock rate, mode, bit order, word width, CS polarity and expected payload. Show that both the raw bits and the decoded table support the conclusion.

Repeat the loopback at a slower requested clock. The clock period should grow while the number of clocks per three-byte burst remains 24. Software gaps may not scale identically with the clock because they come from code overhead. Separate active shifting time from total CS-LOW duration.

If you move beyond 1 MHz, reconsider sample rate, input limits and wiring length before accelerating. The LA1010’s headline rate is not a license to decode every fast bus. A carefully measured low-speed baseline is the reference that lets you identify what changes at higher speed.

At the bench · do this next

  1. Save the 1 MHz baseline and a slower run.
  2. Count clocks, measure active-clock duration and total selected duration.
  3. Explain any non-scaling gaps without assuming the whole burst is one continuous clock train.

Pause & predict

If the clock frequency halves, must CS-LOW duration exactly double?
Reveal the reasoning

Not necessarily. Fixed software gaps and selection overhead may remain roughly unchanged.

Reference trail: K2A7S2S3 · Expected waveforms are teaching predictions, not measured records.
Section 08 · Chapters 071–080

Capture engineering

Triggers, resolution, filters and repeatable measurements

Intermediate skill is choosing a recording that can answer the question. You will learn to preserve context, challenge suspicious evidence and avoid software features that hide the fault.

071 A trigger is a predicate, not a command 072 Keep the cause before the symptom 073 Use the capture-budget calculator 074 Report uncertainty instead of decorative decimals 075 Glitch filtering can erase the bug 076 Separate a real glitch from a probe artifact 077 Use repeat acquisition without losing the rare event 078 Use the LA1010 PWM outputs as a local source 079 Export data without losing its meaning 080 Intermediate checkpoint: design the capture before the code
Chapter 071

A trigger is a predicate, not a command

A trigger says which observed condition should anchor the record. It does not generate the condition in your circuit. Kingst’s manual describes rising/falling edges, HIGH/LOW levels and combinations of levels with one edge, combined logically with AND.

For example, a falling edge on UART_TX finds many character starts and data transitions. Adding a marker HIGH condition restricts it to a particular firmware phase. For SPI, CS falling identifies transaction selection. For I²C, SDA falling while SCL is HIGH approximates a START condition with edge-plus-level qualification.

Do not assume the LA1010 offers hardware triggers on arbitrary decoded bytes or complex sequences merely because it has protocol decoders. Use the documented trigger controls and distinguish capture-time triggering from searching a decoded result after capture. When a compound trigger never fires, remove conditions one at a time and prove each is reachable.

Qualify an edge with a levelQualify an edge with a levelMARKERUART TX
A falling edge on TX AND marker HIGH selects an event inside the marked operation.

At the bench · do this next

  1. Choose the simplest electrical event matching the question.
  2. Clear unused channel conditions.
  3. Add one qualification only after the simple trigger works.

Pause & predict

Does “UART decoder available” imply “trigger on byte 0xA3” is available?
Reveal the reasoning

No. Decoding and hardware trigger capabilities are separate features.

Reference trail: K1K2K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 072

Keep the cause before the symptom

A capture triggered on an error is much more useful if it contains what happened just before the error. Trigger position controls how much of the record precedes and follows the anchor. In the published KingstVIS workflow, it is under device settings, More Settings, Trigger Position.

For a 100 ms record with a 20% trigger position, plan roughly 20 ms before and 80 ms after the trigger, subject to acquisition behavior and adequate prefill. Arm early enough to collect the history. A one-shot event immediately after arming may not provide the full intended pre-event context.

Use a known marker to verify the behavior in your installed version. The manual’s description includes prefill before trigger evaluation; do not assume every product uses identical ring-buffer semantics. Inspect the actual time axis and visible history. When investigating startup, reset the target only after the analyzer is armed and ready.

At the bench · do this next

  1. Set a known finite record and a modest pretrigger percentage.
  2. Arm, wait for readiness, then cause a repeating known event.
  3. Confirm actual before/after coverage rather than relying only on the requested setting.

Pause & predict

Why can an error-triggered trace still fail to explain the error?
Reveal the reasoning

The earlier cause may lie outside the recorded history. Increase pretrigger coverage or trigger on an earlier event.

Reference trail: K1K2K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 073

Use the capture-budget calculator

Choose resolution from the shortest meaningful feature and duration from the longest relevant interval. Then estimate nominal depth as Fs×T. The calculator below checks the LA1010 channel tier and reports sample interval, samples per signal period and requested depth.

It is a planning model, not a hardware simulator. It cannot predict USB reliability, waveform compression, host memory or whether your actual signal obeys its assumed frequency. For pulse signals, calculate samples across the narrowest pulse separately; ten samples per repetition period can still miss a tiny duty pulse.

As an example, four channels at 50 MS/s for 20 ms request one million time samples. A 1 MHz clock receives 50 sample positions per period. If you instead need ten seconds of slow command/response timing, reduce the rate only as far as the fastest relevant bits permit, and verify the actual achieved recording interval.

LA1010 capture planner

Planning arithmetic only. Rates must also be available in your installed KingstVIS. Compression and achievable host duration are not predicted.

At the bench · do this next

  1. Enter enabled channels, sample rate, signal frequency and duration.
  2. Check rate against the channel-dependent maximum.
  3. Choose the nearest supported rate/depth combination in KingstVIS and read back its duration.

Pause & predict

What does the calculator deliberately not predict?
Reveal the reasoning

Actual compressed memory use, USB transfer success, analog integrity or guaranteed pulse detection.

Reference trail: K1K2K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 074

Report uncertainty instead of decorative decimals

At 10 MS/s the sample interval is 100 ns. A measurement displayed as 8.700000 µs has not acquired picosecond precision. Edge localization is quantized, and threshold crossing depends on the physical signal as well.

For a quick conservative width estimate, allow roughly two sample intervals for two edge placements, then remember oscillator and analyzer timebase accuracy are additional terms. This is a teaching uncertainty budget, not a manufacturer calibration specification. Don’t present it as a guaranteed error bound under every condition.

Measuring several periods between markers and dividing can reduce cursor and quantization influence on average frequency. It does not reveal the worst single-period jitter. Decide whether you want mean rate, one pulse width or a distribution of intervals, then choose the measurement method accordingly. Use units consistently and round results to a level supported by the record.

At the bench · do this next

  1. Measure a single period and then ten periods together.
  2. Compare the derived average with the single-period result.
  3. Report sample rate beside timing values that approach its resolution.

Pause & predict

Does averaging ten periods prove every period met its timing limit?
Reveal the reasoning

No. An average can conceal individual outliers.

Reference trail: K1K2K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 075

Glitch filtering can erase the bug

KingstVIS offers per-channel glitch filtering based on pulse width in samples. A filter can simplify noise-contaminated decoding, but it can also remove a real narrow pulse. The threshold in time changes when the sample rate changes: N samples corresponds to N/Fs seconds.

Start with filters disabled and preserve the original capture. Improve ground returns and probe arrangement before treating filtering as a cure. If you later filter for analysis, save a separately identified result and state the setting. A decoder becoming readable after filtering is evidence about its sensitivity, not proof that the circuit is healthy.

Version matters here. Kingst’s v3.6.5 release notes mention a fix involving the first short pulse and filtering. Record your software version whenever a conclusion depends on this feature. Never silently compare a filtered capture with an unfiltered baseline as though they were equivalent measurements.

Filtering changes the evidenceFiltering changes the evidenceOriginalFiltered
A narrow pulse disappears. That may improve decoding or erase the very fault you needed to observe.

At the bench · do this next

  1. Capture and save with all filters off.
  2. If needed, apply a known N-sample filter to a copy or clearly labeled analysis.
  3. Convert the filter setting to time and check whether any valid protocol pulse is shorter.

Pause & predict

At 10 MS/s, what duration is three samples?
Reveal the reasoning

300 ns. A filter at that scale may remove meaningful sub-microsecond events.

Reference trail: K1K2K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 076

Separate a real glitch from a probe artifact

A false transition can come from a floating unused input, long ground lead, crosstalk, poor contact or a marginal threshold. A real glitch can come from firmware, logic hazards or disturbed power. The first trace alone may not distinguish them.

Keep the firmware fixed and alter the measurement in controlled ways: shorten the leads, move the ground return closer, disable unused channels and repeat at higher resolution. Compare a second observation point if practical. If an anomaly follows the probe arrangement rather than the circuit event, suspect measurement interaction.

Do not overstate that test: changing probes also changes loading, so disappearance is a clue rather than final proof. The manual lists input capacitance, which reminds you that a probe is not electrically invisible. When analog cause remains uncertain, use an oscilloscope at the receiver’s pin. A logic analyzer is strongest at locating when and where to look.

LOW-VOLTAGE TARGET probe mapLOW-VOLTAGE TARGETSignal and its referenceKINGST LA1010INPUTS · passive probesLogic signalCH0Circuit GNDGNDUSB links analyzer ground to the computer. Never use a switching node as ground.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
Logic signalCH0
Circuit GNDGND

At the bench · do this next

  1. Save the suspicious unfiltered record.
  2. Change one measurement variable and repeat the same stimulus.
  3. Document whether the anomaly tracks source behavior or probe setup.

Pause & predict

Can a single extra pulse prove a software double-write occurred?
Reveal the reasoning

No. Confirm it with repeatable timing, marker correlation and measurement-quality checks.

Reference trail: K1K2K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 077

Use repeat acquisition without losing the rare event

Automatic repeat acquisition is convenient for a stable repeating source. It is risky when you want to preserve a rare failure, because the next acquisition may replace the interesting record. Stop immediately when the event appears and save before changing settings.

The manual describes repeat behavior options depending on whether triggers are satisfied. Inspect the installed version’s Options dialog rather than assuming it is continuously logging every instant. Between acquisitions there may be gaps; repeated finite captures are not proof of uninterrupted coverage.

For intermittent faults, prefer a trigger that identifies the event or a long enough single record around a controlled reproduction. If no suitable electrical trigger exists, add a firmware error marker or use a simpler external symptom. Record how many trials you observed and whether acquisition gaps could have hidden events. Absence of a captured failure is only meaningful relative to actual coverage.

At the bench · do this next

  1. Use repeat mode only while exploring a stable source.
  2. Stop and save any anomaly immediately.
  3. For rare-event work, design a marker or a longer single acquisition.

Pause & predict

Does “I watched repeat mode for a minute” prove every event during that minute was recorded?
Reveal the reasoning

No. Acquisition gaps and overwritten records can limit coverage.

Reference trail: K1K2K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 078

Use the LA1010 PWM outputs as a local source

The LA1010 includes two PWM generator outputs described in Kingst’s manual. Access their controls through device settings and More Settings. These are active outputs, unlike CH0–CH15 inputs. Treat them as signal generators, not power supplies or motor drivers.

For a self-test, disconnect the target board entirely. Connect the labeled PWM1 output to CH0 and the appropriate analyzer ground reference. Begin with 1 kHz and 50% duty, the manual’s documented default example, then acquire the resulting signal. Verify your particular unit’s output labeling and electrical specifications before connecting it to any external input; this guide does not infer compatibility from the word PWM.

Change duty while holding frequency constant and observe which measurement changes. Turn the output off and disconnect it when finished. Never connect a generator output to a microcontroller pin already configured as a push-pull output. Two outputs fighting each other can damage hardware.

LA1010 PWM1 probe mapLA1010 PWM1Standalone self-test · target removedKINGST LA1010INPUTS · passive probesPWM1 outputCH0 inputGND referenceGNDConceptual loopback on the same instrument. Verify port labels; PWM output is not a supply.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
PWM1 outputCH0 input
GND referenceGND

At the bench · do this next

  1. Remove target-board connections and identify PWM1 versus CH inputs.
  2. Set PWM1 to 1 kHz, 50% through More Settings; observe on CH0.
  3. Change duty, measure, then switch PWM output off.

Pause & predict

Why is PWM1→an actively driven MCU output an invalid loopback?
Reveal the reasoning

Both ends may drive conflicting levels. The local analyzer input loopback avoids that contention.

Reference trail: K1K2K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 079

Export data without losing its meaning

Exported samples and exported decoded records are different datasets. A raw export may represent transitions or sampled states according to the chosen format; inspect its header and actual structure before writing a parser. A decoded export contains protocol events inferred using particular settings.

Keep timestamps in their documented units and preserve the origin. If you crop an interval, note whether exported time remains absolute within the capture or is rebased. Use a known marker to verify the convention. Never silently subtract or scale time until a plot “looks right.”

A useful analysis script computes request-to-response intervals, counts NACKs or checks a known byte sequence. It should also report excluded or incomplete events. The guide’s downloadable notebook template records the interpretation settings alongside the files. Keep the .kvdat source so a later correction to baud, bit order or filtering does not leave you trapped with only derived data.

At the bench · do this next

  1. Export one small known capture and inspect its first rows.
  2. Confirm timestamp units and whether entries are samples, transitions or decoded events.
  3. Compare one exported interval with KingstVIS markers.

Pause & predict

Why keep the native capture after exporting CSV?
Reveal the reasoning

It preserves evidence for different decoder settings and later inspection that a derived table may omit.

Reference trail: K1K2K4 · Expected waveforms are teaching predictions, not measured records.
Chapter 080

Intermediate checkpoint: design the capture before the code

Choose a failure question such as “Does the response arrive within 5 ms after the request finishes?” Define the start event, end event, relevant channels, resolution and minimum record duration. Then choose trigger and pretrigger coverage.

Write an acceptance criterion before acquiring. For example, every complete observed request has a corresponding response-start edge within the limit. State how you will handle incomplete records at capture boundaries. A timestamp from the first byte of a request is not interchangeable with completion of its last stop bit.

Finally, list what the capture cannot establish: unrecorded intervals, analog voltage margin, internal state without markers, or behavior under untested loads. This is not pessimism; it keeps the conclusion proportional to the evidence. Intermediate proficiency means being able to defend both your result and its limits.

At the bench · do this next

  1. Write a capture plan and pass/fail criterion.
  2. Acquire a known-good and a deliberately delayed case.
  3. Produce a short evidence-based diagnosis using identical event definitions.

Pause & predict

What makes a timing claim reproducible?
Reveal the reasoning

Explicit event definitions, actual acquisition settings, preserved raw evidence and a stated scope of observation.

Reference trail: K1K2K4 · Expected waveforms are teaching predictions, not measured records.
Section 09 · Chapters 081–090

The ESP32-S3 companion, correctly understood

Observe the board you actually own

The UNO R4 WiFi is a two-processor system. Learn which behavior belongs to the sketch, which belongs to the connectivity module, and which signals are accessible without altering its firmware.

081 Follow a request across two processors 082 Read the ESP header without guessing orientation 083 Attempt a passive ESP boot-log capture 084 USB serial is not a UART waveform on every pin 085 Measure a real WiFiS3 operation 086 Separate a blocked application from a dead processor 087 Internal nets require a schematic, not intuition 088 Keep firmware recovery separate from measurement 089 Cross-board communication needs voltage translation 090 Companion-module checkpoint: make a bounded claim
Chapter 081

Follow a request across two processors

A Wi-Fi API called by your RA4M1 sketch can ask the ESP32-S3 companion to perform work. The API call, internal communication, radio operation and returned result are distinct stages. A slow call does not automatically mean the main processor was executing calculations for that entire interval.

The ESP companion also participates in the board’s USB/programming connectivity. Replacing its firmware can therefore affect uploads and board detection as well as Wi-Fi. These observation labs preserve the stock connectivity firmware. Arduino’s advanced flashing and restoration guides are linked for context, not required as lab prerequisites.

Start at an accessible boundary: raise a main-board marker before a WiFiS3 call and lower it afterward. That measures the application-visible blocking interval without guessing undocumented packet meanings. If deeper analysis becomes necessary, identify actual schematic nets and firmware versions before probing them.

UNO R4 WiFi voltage and processor domainsRA4M1Main Arduino sketchOrdinary headers: 5 VESP32-S3Wi-Fi / USB bridgeESP header: 3.3 VOnboard leveltranslationQwiic: separate 3.3 V bus, Wire1. Ordinary SDA/SCL headers: Wire.
Functional architecture, not a complete schematic. Onboard translation protects specific internal nets, not every external connection.

At the bench · do this next

  1. Identify the main sketch’s call boundary.
  2. Choose an unused RA4M1 marker such as D7.
  3. Write what the marker does and does not measure.

Pause & predict

Does a D7 marker around a Wi-Fi call measure radio airtime alone?
Reveal the reasoning

No. It includes application-visible processing, communication and waiting inside that call.

Reference trail: A2A3A8A9A10E1 · Expected waveforms are teaching predictions, not measured records.
Chapter 082

Read the ESP header without guessing orientation

Arduino documents a six-pin ESP header: pin 1 GPIO42, pin 2 GPIO41, pin 3 ESP_TXD0/GPIO43, pin 4 ESP_DOWNLOAD/GPIO0, pin 5 ESP_RXD0/GPIO44 and pin 6 GND. These are 3.3 V-domain connections. Confirm pin 1 and physical orientation against the official drawing before touching the board.

The diagram here is a numbered connection map, not a promise that every viewing angle matches the page orientation. Use a magnifier and the official pinout. If hooks cannot attach without touching adjacent pads, use a suitable breakout or postpone that physical observation.

For passive UART observation, CH0 can observe ESP_TXD0 and GND goes to pin 6. Leave boot/download and other pins unconnected. Do not attach 5 V UART outputs or the UNO’s D1 directly. An analyzer input observes a signal; a USB-UART adapter TX lead actively drives it and creates a different experiment.

UNO · ESP header probe mapUNO · ESP header3.3 V only · verify pin-1 orientationKINGST LA1010INPUTS · passive probes3 · GPIO43 / TXD0CH06 · GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
3 · GPIO43 / TXD0CH0
6 · GNDGND

At the bench · do this next

  1. Locate pin 1 using source A2 and verify numbering.
  2. With power off, attach GND and CH0→ESP_TXD0 only if mechanically secure.
  3. Use 1.5 V threshold and leave boot/control pins untouched.

Pause & predict

Is ESP_RXD0 on header pin 5 the same net as Arduino D0?
Reveal the reasoning

No. They belong to different processors and voltage domains.

Reference trail: A2A3A8A9A10E1 · Expected waveforms are teaching predictions, not measured records.
Chapter 083

Attempt a passive ESP boot-log capture

Some ESP firmware and boot configurations emit UART messages during startup; content and availability depend on firmware and boot settings. Treat this as an observation exercise with an uncertain outcome, not a guarantee of text.

Keep the analyzer powered by the computer. With its input passively attached to ESP_TXD0, arm a long enough single capture at 10 MS/s and 1.5 V threshold, then power-cycle the target board using its own connection. A falling-edge trigger can anchor the first visible UART activity. If it waits, stop and try an untriggered record to inspect the line state.

Try 115200 8N1 as a starting hypothesis only if measured bit timing supports it. Do not infer baud solely from a familiar ESP tutorial. A quiet line may mean no logging on that pin, not a dead chip. Save the waveform and firmware context whether or not it decodes.

At the bench · do this next

  1. Arm before power-cycling the target, keeping analyzer USB connected.
  2. Measure bit time before accepting a decoder setting.
  3. Record “no observed activity” honestly if the selected firmware is quiet.

Pause & predict

Does an empty capture on ESP_TXD0 prove the ESP failed to boot?
Reveal the reasoning

No. Logging may be disabled, routed elsewhere, missed by the capture, or absent on that firmware.

Reference trail: A2A3A8A9A10E1 · Expected waveforms are teaching predictions, not measured records.
Chapter 084

USB serial is not a UART waveform on every pin

Serial Monitor gives a software-visible stream, but its physical route depends on board architecture. USB signaling is not identical to logic-level asynchronous UART, and the ESP bridge participates in the UNO R4 WiFi’s computer-facing path.

Do not clip LA1010 leads to USB D+/D− and apply the UART decoder. USB uses differential signaling and a different protocol. The UART labs deliberately use Serial1 on accessible main-board pins or passively observe a documented ESP UART pin.

When tracing a missing print message, distinguish the sketch’s output API, internal bridge route, USB enumeration and host application. A marker showing that the sketch reached a print call does not prove the host received the bytes. Conversely, a Serial Monitor message does not prove that external D1 carried it. Use the schematic and API mapping to select the observation point.

At the bench · do this next

  1. Name the API: Serial or Serial1.
  2. Identify its documented physical route.
  3. Keep the external Serial1 test as a separate known-good baseline.

Pause & predict

Can a UART decoder interpret USB D+ as if it were D1/TX?
Reveal the reasoning

No. They are different electrical and protocol layers.

Reference trail: A2A3A8A9A10E1 · Expected waveforms are teaching predictions, not measured records.
Chapter 085

Measure a real WiFiS3 operation

Upload the scan-timing sketch. It raises D7, calls WiFi.scanNetworks using the stock WiFiS3 library, lowers D7 and waits five seconds. It requires no stored Wi-Fi credentials. Probe D7 and GND at a 2.5 V threshold.

Scans can take seconds, so begin with a long capture at a modest rate such as 100 kS/s or the nearest suitable offered rate. The marker is slow; high-rate protocol decoding is not the question. Trigger on its rising edge and leave enough post-trigger time for completion. If the marker stays HIGH beyond the record, extend the window rather than claiming a permanent hang.

Measure ten scans and record complete intervals separately from truncated ones. Nearby networks and radio conditions can affect the operation. This is an application-visible latency distribution, not measurement of individual Wi-Fi frames. LA1010 is not a radio packet sniffer.

UNO R4 WiFi probe mapUNO R4 WiFiRA4M1 marker · stock WiFiS3KINGST LA1010INPUTS · passive probesD7 · scan activeCH0GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
D7 · scan activeCH0
GNDGND
uno_wifi_timing.ino
UNO R4 WiFi · time a stock WiFiS3 network scan · no credentials
Read the complete program
#include <WiFiS3.h>
volatile int networks=0;
void setup() {
  pinMode(7, OUTPUT); digitalWrite(7, LOW);
}
void loop() {
  digitalWrite(7, HIGH);
  networks=WiFi.scanNetworks();
  digitalWrite(7, LOW);
  delay(5000);
}

At the bench · do this next

  1. Upload uno_wifi_timing.ino and probe D7.
  2. Choose a seconds-long post-trigger window.
  3. Measure several complete HIGH intervals and note incomplete ones separately.

Pause & predict

Why use a lower rate here than for SPI?
Reveal the reasoning

The measured event lasts seconds and only call-boundary timing matters. Higher rate consumes resources without answering a finer question.

Reference trail: A2A3A8A9A10E1 · Expected waveforms are teaching predictions, not measured records.
Chapter 086

Separate a blocked application from a dead processor

A long marker interval around a blocking function tells you the call has not returned. It does not prove the processor has stopped executing entirely. The function may be waiting, processing internal messages or running code while the main loop cannot advance.

A second marker at the top of loop shows main-loop progress, but it also stops during a blocking call by design. To investigate other execution, use an independent hardware timer output, an interrupt marker or a debugger observation with its timing limitations understood. Each marker needs a narrowly defined meaning.

Compare the Wi-Fi call boundary with a hardware-generated PWM output in an appropriately configured experiment. Continued PWM demonstrates that the peripheral runs, not that every software subsystem is healthy. This layered interpretation prevents one symptom from becoming an unsupported claim about the whole board.

At the bench · do this next

  1. Define which execution context owns each marker.
  2. Compare loop progress with an independent peripheral signal if needed.
  3. Distinguish “call not returned” from “CPU halted.”

Pause & predict

Does continuing hardware PWM prove the application loop is responsive?
Reveal the reasoning

No. A timer can continue while application code waits or is stuck.

Reference trail: A2A3A8A9A10E1 · Expected waveforms are teaching predictions, not measured records.
Chapter 087

Internal nets require a schematic, not intuition

The schematic shows level translation and internal connections between processors. A header pin named ESP_TXD0 does not automatically expose the communication used by every Wi-Fi library operation. Trace actual net names and peripheral assignments for your board and firmware version.

Before probing an internal pad, ask whether the measurement can be made at an accessible boundary. Fine-pitch probing can short adjacent pins or add loading. Use proper test points or a breakout; do not balance loose hooks on IC legs.

If you observe an internal link, document which side of a translator you measured and its voltage domain. A byte stream may use a private firmware protocol rather than AT commands. Decode timing first, then establish semantics from the relevant source or documented protocol. Do not send guessed commands into a working bridge as a shortcut.

UNO R4 WiFi voltage and processor domainsRA4M1Main Arduino sketchOrdinary headers: 5 VESP32-S3Wi-Fi / USB bridgeESP header: 3.3 VOnboard leveltranslationQwiic: separate 3.3 V bus, Wire1. Ordinary SDA/SCL headers: Wire.
Functional architecture, not a complete schematic. Onboard translation protects specific internal nets, not every external connection.

At the bench · do this next

  1. Trace one named net in the board schematic.
  2. Check voltage domain and physical accessibility.
  3. Prefer passive observation and preserve working firmware.

Pause & predict

Why can the same logical connection have different voltages at two points?
Reveal the reasoning

A level translator can sit between them. Probe location matters even when the information is related.

Reference trail: A2A3A8A9A10E1 · Expected waveforms are teaching predictions, not measured records.
Chapter 088

Keep firmware recovery separate from measurement

Arduino provides an advanced custom-ESP-firmware procedure and separate connectivity firmware update/restoration instructions. These can change how the board appears to your computer. They are maintenance or development operations, not prerequisites for learning LA1010.

Record the board core and connectivity firmware versions when diagnosing bridge behavior. If a regression is suspected, preserve evidence before changing versions. Otherwise you may remove the symptom without establishing which layer failed.

When restoration is needed, follow the current official procedure linked in the appendix. Do not improvise boot-pin shorts or apply instructions intended for a generic ESP32 board. The UNO’s bridge role creates a different recovery context. After restoration, repeat an ordinary sketch upload and known Serial1 capture before returning to advanced observations.

At the bench · do this next

  1. Record software and firmware versions where available.
  2. Save failing evidence before updating.
  3. After any necessary recovery, re-establish the simple baselines.

Pause & predict

Must you overwrite ESP firmware to use LA1010 with UNO R4 WiFi?
Reveal the reasoning

No. All required labs here work with the stock bridge/connectivity firmware.

Reference trail: A2A3A8A9A10E1 · Expected waveforms are teaching predictions, not measured records.
Chapter 089

Cross-board communication needs voltage translation

The UNO’s ordinary UART/SPI outputs are 5 V-domain signals; Nucleo and ESP logic use 3.3 V. The analyzer’s ability to observe both does not make a direct MCU-to-MCU connection acceptable. Measurement tolerance and receiver tolerance are different specifications.

For a later cross-board UART lab, use a direction-aware translator with appropriate supply ranges, thresholds and speed. For I²C, choose a bidirectional open-drain translation arrangement with correct pull-ups. Do not assume a generic translator suits fast push-pull SPI equally well.

Plan each direction separately: source voltage, receiver limits, behavior when either side is unpowered and ground reference. Even 3.3 V into a 5 V receiver needs a guaranteed HIGH-threshold check. This guide establishes each board independently first, so a translation problem cannot masquerade as an analyzer setup problem.

At the bench · do this next

  1. Draw a direction arrow for each planned signal.
  2. Check input tolerance and guaranteed HIGH/LOW thresholds.
  3. Use a documented translator before attempting a cross-board protocol test.

Pause & predict

Why does “the analyzer accepts 5 V” not establish that STM32 RX accepts it?
Reveal the reasoning

They are separate input circuits. One device’s tolerance protects neither the other device nor the wire connection.

Reference trail: A2A3A8A9A10E1 · Expected waveforms are teaching predictions, not measured records.
Chapter 090

Companion-module checkpoint: make a bounded claim

Build a report for the Wi-Fi scan experiment. State that the marker measures entry-to-return duration of WiFi.scanNetworks on the main sketch. Include complete and incomplete captures separately and record the chosen time window.

If you also observed ESP UART activity, present it separately unless you established the link’s meaning. Correlation suggests a relationship, but a burst during a scan does not identify its protocol or payload semantics.

Distinguish application timing, internal digital communication, USB connectivity and radio behavior. LA1010 contributes strongly to the first two when signals are accessible. It does not become a Wi-Fi RF analyzer because the board contains a radio. Knowing that boundary helps you select the next useful instrument or observation point.

At the bench · do this next

  1. Save the full scan-marker capture and code.
  2. Describe exactly what the measured interval includes.
  3. Identify any deeper question needing another observation point.

Pause & predict

What does a two-second scan marker establish?
Reveal the reasoning

The instrumented call took about two seconds to return in that observed run, within measurement resolution.

Reference trail: A2A3A8A9A10E1 · Expected waveforms are teaching predictions, not measured records.
Section 10 · Chapters 091–100

Debug real projects with evidence

From RC signals to your own measurement plan

These capstones connect digital measurements to motors, sensors and control code. Start with signal-only tests, then use the same reasoning on a fully specified low-voltage system.

091 Build a symptom-to-test decision tree 092 Measure an RC servo command without a servo 093 Observe motor-driver logic, not the motor node 094 Quadrature encoders: direction lives between channels 095 Sensor timing: data-ready to completed read 096 Find startup and reset ordering problems 097 Build a known-good fingerprint 098 Capstone: diagnose three deliberate faults 099 Capstone: an RC control timing test 100 Your independent debugging workflow
Chapter 091

Build a symptom-to-test decision tree

“It does not work” is too broad. Translate it into an observable symptom: no clock, no acknowledgment, wrong bytes, late response, duplicate pulse or reset during activity. Choose the smallest experiment that separates two plausible causes.

For no activity, check power, ground, routing and execution. For activity with bad decode, check rate, threshold, mapping and protocol settings. For valid requests without responses, inspect selection, address, command semantics and readiness. For intermittent corruption, preserve raw evidence and compare electrical conditions.

Write each test as a prediction. “If the wrong Wire object is selected, A4/A5 will show traffic while Qwiic remains idle.” A result then changes what you believe. Keep the known-good baseline available so you can distinguish a new fault from a broken measurement setup.

Measurement concept mapFollow the evidence through four layersSOURCECONNECTIONACQUISITIONDECODING
Original teaching illustration. All waveform examples in the guide are illustrative unless explicitly described as your own capture.

At the bench · do this next

  1. Choose one symptom and two plausible causes.
  2. Design a capture whose outcomes distinguish them.
  3. Change one variable, acquire and update the diagnosis.

Pause & predict

Why not change baud, wiring and threshold simultaneously?
Reveal the reasoning

Even if it works afterward, you cannot tell which change mattered or whether one fault masked another.

Reference trail: K2S2N1 · Expected waveforms are teaching predictions, not measured records.
Chapter 092

Measure an RC servo command without a servo

Many hobby servos use pulse-width commands with a repeating frame, often around 20 ms, but accepted ranges and meanings vary. Begin with the signal-only example: D7 requests 1.5 ms HIGH and 18.5 ms LOW. No motor or servo is attached.

Capture several frames at 1 MS/s or higher. Measure HIGH width and period independently. The software-delay example includes call overhead, so observe its actual timing. A nominal 1.5 ms pulse in a 20 ms frame is about 7.5% duty, not 50%.

When adding a real servo, use its specified voltage, pulse range and an adequate power arrangement. The analyzer observes the command relative to logic ground; it does not measure shaft position, torque or supply current. A perfect command cannot prove that the mechanical system obeyed it.

UNO R4 WiFi probe mapUNO R4 WiFiSignal-only lab · no servo attachedKINGST LA1010INPUTS · passive probesD7 · command pulseCH0GNDGNDPower target off while attaching leads. Each board uses its own power connection.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
D7 · command pulseCH0
GNDGND
uno_servo_signal.ino
UNO R4 WiFi · signal-only servo-style pulse · do not attach a motor
Read the complete program
const uint8_t signalPin=7;
void setup() { pinMode(signalPin,OUTPUT); digitalWrite(signalPin,LOW); }
void loop() {
  // Deliberately simple software timing. Measure its actual period.
  digitalWrite(signalPin,HIGH); delayMicroseconds(1500);
  digitalWrite(signalPin,LOW);  delayMicroseconds(18500);
}

At the bench · do this next

  1. Upload uno_servo_signal.ino without a servo.
  2. Measure pulse width and repetition separately.
  3. Change HIGH/LOW delays while preserving the intended frame, then predict and measure.

Pause & predict

Does 1.5 ms guarantee a physically centered shaft?
Reveal the reasoning

No. Calibration, servo type, mechanics, power and specifications determine position.

Reference trail: K2S2N1 · Expected waveforms are teaching predictions, not measured records.
Chapter 093

Observe motor-driver logic, not the motor node

A driver may accept PWM, direction, enable and fault signals. Those low-voltage control signals are good analyzer targets. Motor terminals and switching nodes are a different environment and are outside these direct-probe bench labs.

Start with the motor disconnected and a documented control interface. Capture enable, PWM and direction. Verify startup states and required sequencing before introducing a load. Some drivers use IN1/IN2 truth tables rather than separate PWM/DIR semantics; read the specific table.

When testing a powered system, manage ground paths and motor-current returns. Probe only verified logic nets, never reference a switching terminal with analyzer ground, and use suitable analog/current tools for supply dips or current. LA1010 can reveal that a fault pin asserted after PWM began; it cannot alone explain the power-stage cause.

MOTOR DRIVER probe mapMOTOR DRIVERProbe verified logic side onlyKINGST LA1010INPUTS · passive probesPWM / commandCH0DIR / directionCH1FAULT logicCH2Logic GNDGNDMotor terminals and switching nodes are NOT connected to the analyzer.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
PWM / commandCH0
DIR / directionCH1
FAULT logicCH2
Logic GNDGND

At the bench · do this next

  1. Read the driver truth table and input limits.
  2. Capture logic commands with the load disconnected first.
  3. Compare enable/direction/PWM ordering with its requirements.

Pause & predict

Can you connect CH0 and GND across motor terminals like an isolated voltmeter?
Reveal the reasoning

No. The analyzer ground is USB-referenced; it is not an isolated differential measurement.

Reference trail: K2S2N1 · Expected waveforms are teaching predictions, not measured records.
Chapter 094

Quadrature encoders: direction lives between channels

A quadrature encoder produces phase-related A and B signals. Direction follows their state order. A common sequence is 00→01→11→10→00; reversing the order reverses interpreted direction. Which physical rotation is “forward” depends on wiring and convention.

Capture both channels together with appropriate pull-ups if required. Choose enough sample rate to resolve the shortest state interval at maximum speed. Count transitions rather than just one channel’s pulses if firmware uses ×4 decoding.

An invalid jump such as 00→11 can mean missing intermediate samples, noise or a signaling fault. Repeat at higher resolution, check ground and compare firmware counts with captured states. Mechanical contact encoders may bounce; filtering must preserve legitimate short states at speed. A slow hand-turned baseline helps establish the correct sequence first.

Two channels encode directionTwo channels encode directionAB
The state sequence is 00 → 01 → 11 → 10. Reversing the order reverses the direction convention.

At the bench · do this next

  1. Document the forward A/B sequence.
  2. Capture slow motion and list the states.
  3. Compare the analyzer count with the firmware’s ×1, ×2 or ×4 convention.

Pause & predict

Why might counts differ by exactly four?
Reveal the reasoning

The two methods may count one full cycle versus all four quadrature transitions.

Reference trail: K2S2N1 · Expected waveforms are teaching predictions, not measured records.
Chapter 095

Sensor timing: data-ready to completed read

A sensor may announce data with an interrupt or data-ready pin. Capture that pin beside I²C or SPI and a firmware marker if useful. You can separate sensor-ready time, firmware response latency, transaction duration and later processing.

Put A1 at the documented active data-ready edge and A2 at the first bus action. That measures response latency at those observation points. Measure bus completion separately. A late read might result from polling, interrupt priority, a blocked loop or contention.

Polarity, clearing behavior and freshness rules are device-specific. Some flags stay asserted until read; others pulse. Do not assume every edge denotes an independent sample. If transactions are correct but values repeat, compare read timing with the sensor update period. A valid bus exchange and a fresh physical measurement are separate claims.

At the bench · do this next

  1. Choose a sensor with documented data-ready behavior.
  2. Capture data-ready and the full read together.
  3. Split total delay into waiting, bus transfer and later processing.

Pause & predict

Does a fast read guarantee a fresh sample?
Reveal the reasoning

No. Freshness depends on conversion/update timing and register semantics.

Reference trail: K2S2N1 · Expected waveforms are teaching predictions, not measured records.
Chapter 096

Find startup and reset ordering problems

Failures may occur only at startup because components become ready at different times. Capture reset, enable, chip select and the first request where accessible. Arm before resetting the target.

Look for initial output states, premature commands and repeated reset-like patterns. A GPIO may start as an input and float before initialization. External pull resistors may be needed for a safe default; their polarity and strength must match the actual interface requirements.

A captured reset pulse does not reveal every reset cause or supply transient. Correlate with reset-cause registers and an oscilloscope on the supply when necessary. Debugger reset can differ from true power-on. Test them separately and state which sequence produced each capture.

At the bench · do this next

  1. Separate power-on, button-reset and debugger-reset tests.
  2. Capture initial states and the first request.
  3. Compare required ready delays with observed commands.

Pause & predict

Why can code work after debugger reset but fail at power-on?
Reveal the reasoning

Power stabilization, peripheral readiness and reset sequences may differ.

Reference trail: K2S2N1 · Expected waveforms are teaching predictions, not measured records.
Chapter 097

Build a known-good fingerprint

Save a representative trace for each working subsystem: UART exchange, identity-register read, display initialization, PWM startup or sensor interrupt cycle. Keep firmware version, settings and interpretation with it.

A fingerprint includes raw data and enough context to identify the transaction. When a later revision fails, compare structure first: event order, selection, clock count, address, acknowledgment and timing. Then compare payloads that may legitimately change.

Automated comparisons should tolerate expected variation and highlight meaningful deviations. Sensor values change naturally; a missing STOP or extra CS edge may not. Define invariants and timing ranges. A golden trace is a reference experiment, not a requirement that every future run match byte-for-byte. Periodically reopen a saved fingerprint to confirm the context remains understandable.

At the bench · do this next

  1. Save one complete good transaction per subsystem.
  2. Mark invariant fields and acceptable timing ranges.
  3. Use the reference when changing firmware, wiring or clocks.

Pause & predict

Should every sensor byte match a golden trace?
Reveal the reasoning

Usually not. Compare structure and expected ranges while allowing the measured quantity to vary.

Reference trail: K2S2N1 · Expected waveforms are teaching predictions, not measured records.
Chapter 098

Capstone: diagnose three deliberate faults

Use only isolated practice circuits. Fault one is a UART decoder baud mismatch with unchanged firmware. Fault two is swapped I²C SDA/SCL assignments in the decoder. Fault three is a wrong STM32 timer alternate function in firmware. Save and restore a baseline for each.

Write the symptom, two hypotheses, a discriminating test, evidence and correction. The first two faults change interpretation while the third changes physical output. Calling all three “bad waveforms” conceals the useful distinction.

Add a fourth fault: shorten the capture until it truncates a valid message. This is an acquisition-design error; neither source nor decoder is wrong. Your task is to identify which layer needs correction—source, wiring, acquisition or interpretation—before editing the project. Reacquire the good state after every correction.

At the bench · do this next

  1. Reproduce each fault individually.
  2. Explain the failing layer using preserved evidence.
  3. Restore and recapture the baseline each time.

Pause & predict

A byte ends halfway at the record’s right edge. What should you test first?
Reveal the reasoning

Extend the capture window or change trigger position. The record may simply be truncated.

Reference trail: K2S2N1 · Expected waveforms are teaching predictions, not measured records.
Chapter 099

Capstone: an RC control timing test

Imagine a controller with command input, motor PWM, direction, servo command and fault input. Begin signal-only with no moving load. Define requirements: a valid command must affect the next control update within a chosen interval; a fault must disable drive within another.

Map channels to command boundary, update marker, PWM, direction, servo pulse and fault. Six enabled channels allow up to 50 MS/s, but slower rates may suffice. Preserve enough rate for any UART command stream. A firmware radio-receive marker describes an application boundary, not RF reception directly.

Test normal commands, missing commands and a simulated logic fault using the actual input specification. Measure ordering and latency. Introduce real hardware only after its electrical and mechanical requirements are addressed. LA1010 verifies selected control decisions; separate tests validate current, temperature, movement and stopping performance.

RC CONTROL · BENCH probe mapRC CONTROL · BENCHSignal-only planning mapKINGST LA1010INPUTS · passive probesCommand markerCH0Update markerCH1PWM logicCH2Direction logicCH3Servo commandCH4Fault logicCH5Logic GNDGNDSix inputs: up to 50 MS/s. Verify every signal voltage before connecting.
Conceptual top-view wiring map; connector positions are simplified. Follow pin labels and the official pinout, not drawing coordinates.
Target connectionAnalyzer connection
Command markerCH0
Update markerCH1
PWM logicCH2
Direction logicCH3
Servo commandCH4
Fault logicCH5
Logic GNDGND

At the bench · do this next

  1. Write two timing requirements with explicit start/end events.
  2. Design a channel map and capture budget.
  3. Record a pass and an intentional delay/fault case, then explain them.

Pause & predict

Can this certify stopping distance?
Reveal the reasoning

No. It validates selected signal timing. Braking dynamics, traction, power and mechanics need separate tests.

Reference trail: K2S2N1 · Expected waveforms are teaching predictions, not measured records.
Chapter 100

Your independent debugging workflow

Start from an unfamiliar board and build an evidence chain: identify the interface, establish voltage and ground, locate pins, predict events, choose resolution and duration, capture, inspect raw timing, decode and test the hypothesis.

Keep the first experiment small. Prefer a known output or fixed register value over a large application. Preserve baselines before faults. When evidence contradicts expectation, challenge both the system and measurement. Good debugging explains why observations support one cause over another.

Use the appendix to return to primary documentation: Kingst for controls, board documents for routing, MCU manuals for registers and peripheral specifications for message meaning. This guide’s code and illustrations are original teaching examples. They have not been validated on your physical devices. Build and observe every checkpoint rather than treating an expected waveform as a recorded result.

At the bench · do this next

  1. Complete an independent capture with a written hypothesis.
  2. Save native data, source version, pin map, settings and conclusion.
  3. Reopen it later and check that someone else could reproduce your reasoning.

Pause & predict

What is the final skill?
Reveal the reasoning

Turning a symptom into a controlled, reproducible measurement and making only claims the evidence supports.

Reference trail: K2S2N1 · Expected waveforms are teaching predictions, not measured records.
Keep beside your instrument

The bench reference card

Before connecting

Power target off. Identify the domain and GND. Connect analyzer GND to circuit GND, then inputs. Keep active PWM outputs disconnected. Inspect for shorts. Power up. Confirm the device is connected, select channels, set threshold/rate/depth, clear unintended triggers and filters, then capture.

LabSignal → inputInitial settings
UNO pulseD7→CH0, D8→CH1, GND→GND2.5 V; 1 MS/s; ~100 ms
STM32 pulsePA5/D13→CH0, GND→GND1.5 V; 1 MS/s; ~20 ms
UNO UARTD1→CH0, D7→CH1, GND→GND2.5 V; 10 MS/s; 115200 8N1
STM32 UARTPA9/D8→CH0, PB6/D10→CH11.5 V; 10 MS/s; USART1, 115200 8N1
UNO I²CA4 SDA→CH0, A5 SCL→CH15 V pull-ups; 2.5 V threshold; 10 MS/s
STM32 I²CPB9/D14 SDA→CH0, PB8/D15 SCL→CH13.3 V pull-ups; 1.5 V threshold; 10 MS/s
UNO SPID13 SCK→CH0, D11 MOSI→CH1, D12 MISO→CH2, D10 CS→CH32.5 V; 50 MS/s; mode 0, MSB, 8-bit
STM32 SPIPA5/D13 SCK→CH0, PA7/D11 MOSI→CH1, PA6/D12 MISO→CH2, PB6/D10 CS→CH31.5 V; 50 MS/s; mode 0, MSB, 8-bit

Every experiment needs common GND even when omitted from a compact table row. Example thresholds suit clean nominal logic; confirm real transmitter/receiver levels for marginal interfaces. Choose the nearest available KingstVIS rate and recalculate depth.

RelationshipUse
Ts = 1/FsTime between samples
Trecord = depth/FsNominal requested duration
f = 1/T; duty = tHIGH/TFrequency and duty are different from pulse width
Tbit = 1/baud; 8N1 frame = 10/baudUART timing before gaps
fPWM = fTIM/[(PSC+1)(ARR+1)]Edge-aligned timer example; verify the actual fTIM
I²C first byte = (address<<1)|R/WRelate seven-bit addresses to raw first bytes

Vocabulary you can use precisely

ThresholdVoltage decision boundary used by the analyzer.
Sample rateDecisions per second, not signal frequency.
DepthNumber of requested time samples, not a guaranteed RAM size.
TriggerObserved condition that anchors acquisition.
LatencyTime from a defined event to a defined response.
JitterVariation of timing around a reference or expected sequence.
Open drainOutput drives LOW or releases; a pull-up produces HIGH.
DecoderInterpretation of sampled logic using protocol settings.
CPOL / CPHASPI idle clock level / sampling-edge phase.
Pretrigger historyRecorded context preceding the triggering event.
Complete checkpoint sources

Practice program shelf

Download one program at a time. For Arduino, put each .ino in its own same-named sketch folder. For STM32, use the downloaded content as the single main.c in the CMSIS project described in Chapter 32. Programs are intentionally separate, not a combined application.

uno_pulse.ino
UNO R4 WiFi · two timing signals · D7 and D8
uno_pwm.ino
UNO R4 WiFi · hardware PWM staircase on D6
uno_button.ino
UNO R4 WiFi · raw and debounced button · D2 to GND
uno_uart.ino
UNO R4 WiFi · known UART bytes · D1 TX, D7 marker
uno_echo.ino
UNO R4 WiFi · local UART loopback · D1 to D0 through 1 kΩ
uno_i2c_probe.ino
UNO R4 WiFi · safe address-only I²C probe · A4/A5
uno_spi_loopback.ino
UNO R4 WiFi · SPI mode 0 · D11 to D12 through 1 kΩ
uno_wifi_timing.ino
UNO R4 WiFi · time a stock WiFiS3 network scan · no credentials
uno_servo_signal.ino
UNO R4 WiFi · signal-only servo-style pulse · do not attach a motor
stm_pulse_main.c
NUCLEO-F411RE · PA5/D13 pulse · nominal 16 MHz HSI
stm_pwm_main.c
NUCLEO-F411RE · TIM3_CH1 on PA6/D12 · 1 kHz, 25%
stm_uart_main.c
NUCLEO-F411RE · USART1 PA9/D8 TX · 115200 nominal
stm_spi_main.c
NUCLEO-F411RE · SPI1 PA5/6/7 · PB6/D10 CS
stm_i2c_observe_main.c
NUCLEO-F411RE · teaching I²C bit-bang · PB8 SCL/PB9 SDA · no target required

Validation boundary: code and register choices were reviewed against the cited sources. No Arduino-core build, STM32 target build, flash, electrical measurement or motor test was performed during authoring. Checkpoint results are predictions for you to verify.

Your evidence, in your words

Lab notebook

Notes and checkmarks stay in this browser when local storage is available. Export periodically; browser storage can be cleared and may vary for local files.

Research notebook · 29 September 2026

Sources, scope and version notes

Research prioritizes Kingst, Arduino, STMicroelectronics, NXP and Espressif. The manufacturer PDF manuals were retrieved and the relevant sections read. Board/core mappings were cross-checked. Explanations, worked examples, programs and diagrams are newly authored for this course.

Version gap: the official Kingst manual download is v3.5 (2020), while the software listing and release log show v3.6.6 (2026). This guide therefore labels its interface drawing as a functional map and avoids claiming it is a current screenshot. The software was not installed or operated against an LA1010 during authoring.

Model boundaries: LA1010 streams to the host; family-manual descriptions of onboard memory and other models must not be generalized to it. Supported-protocol counts, advanced triggers and maximum PWM-generator electrical specifications are not assumed from reseller listings. PWM output use is restricted to a local self-test until the actual unit specifications are checked.

K1 · Kingst · LA1010 product comparisonhttps://www.qdkingst.com/en/products/LA1010

Channel/rate limits, maximum digital frequency, pulse-width claim and conditional compression depth. Accessed 29 September 2026.

K2 · Kingst · Virtual Instruments User Guide v3.5https://www.qdkingst.com/download/vis_ug_en

Official download retrieved and read. Document dated 12 December 2020, 39 pages. Model specifications p. 5; installation/interface pp. 7–9; grounding pp. 10–11; acquisition/trigger/measurements pp. 12–20; channels/filter/save/export pp. 21–27; PWM/trigger position pp. 27–28; protocol configuration pp. 31–36. Its generic memory discussion must not be mistaken for LA1010 onboard memory.

K3 · Kingst · current software downloadshttps://www.qdkingst.com/en/download

Lists v3.6.6 at the research date, with Windows x86, macOS x86-64 and Linux x86-64 packages. This is the official installation entry point; package availability may change.

K4 · Kingst · release historyhttps://www.qdkingst.com/vis/ulog/en-US

v3.6.6 dated 3 August 2026; v3.6.5 dated 30 October 2025. Used to distinguish current software from the older published manual, including UART auto-baud and filter changes.

K5 · Kingst · supported protocol listhttps://www.qdkingst.com/en/plist

Manufacturer’s compatibility entry point. Page retrieval was unreliable during research; this guide does not assert an exhaustive current protocol count or CAN-FD support for LA1010. UART, I²C and SPI are covered by the retrieved official manual.

A1 · Arduino · UNO R4 WiFi hardwarehttps://docs.arduino.cc/hardware/uno-r4-wifi/

Primary board overview; RA4M1 main processor, ESP32-S3 companion and 5 V ordinary GPIO domain.

A2 · Arduino · UNO R4 WiFi full pinouthttps://docs.arduino.cc/resources/pinouts/ABX00087-full-pinout.pdf

Physical mapping, SPI/UART/I²C headers, ESP six-pin header and explicit 3.3 V warnings. Follow its orientation marks on the actual board.

A3 · Arduino · UNO R4 WiFi datasheethttps://docs.arduino.cc/resources/datasheets/ABX00087-datasheet.pdf

Retrieved 46-page board document. Processor roles, voltage domains, level translator, ESP header and Qwiic interface. Document generation dates may change independently of board revisions.

A4 · Arduino · UNO R4 WiFi schematichttps://docs.arduino.cc/resources/schematics/ABX00087-schematics.pdf

Primary reference for tracing internal nets and level translation. Consult the drawing matching your board revision before internal probing.

A5 · Arduino · Renesas core UNO R4 WiFi pin definitionshttps://github.com/arduino/ArduinoCore-renesas/blob/main/variants/UNOWIFIR4/pins_arduino.h

Current source confirms ordinary Wire/Wire1 and SPI mappings. Main branch is mutable: record the core version installed for your own experiments.

A6 · Arduino · UNO R4 WiFi user manualhttps://docs.arduino.cc/tutorials/uno-r4-wifi/cheat-sheet/

Board API and interface overview. Some documentation pages require JavaScript; the linked datasheet and official core provide accessible cross-checks.

A7 · Arduino · official SPI reference sourcehttps://github.com/arduino/reference-en/blob/master/Language/Functions/Communication/SPI.adoc

SPI API concepts and UNO R4 pin mapping. Programs here are original teaching examples, not copied library examples.

A8 · Arduino · custom ESP firmware, advancedhttps://docs.arduino.cc/tutorials/uno-r4-wifi/esp32-upload/

Explains companion firmware and bridge implications. Not required for the passive observation labs.

A9 · Arduino · update connectivity firmwarehttps://support.arduino.cc/hc/en-us/articles/9670986058780-Update-the-connectivity-module-firmware-on-UNO-R4-WiFi

Current supported update path when maintenance is needed.

A10 · Arduino · restore connectivity firmwarehttps://support.arduino.cc/hc/en-us/articles/16379769332892-Restore-the-USB-connectivity-firmware-on-UNO-R4-WiFi-with-espflash

Recovery reference if USB connectivity firmware has been replaced or damaged. Follow the current official instructions.

S1 · STMicroelectronics · UM1724 Nucleo-64 board manualhttps://www.st.com/resource/en/user_manual/um1724-stm32-nucleo64-boards-mb1136-stmicroelectronics.pdf

Retrieved Rev 17, September 2025. F411RE connector table pp. 44–45, board-specific routing and solder-bridge information. Dedicated PB8/PB9 I²C headers avoid assuming A4/A5 bridge routing.

S2 · STMicroelectronics · RM0383 STM32F411 reference manualhttps://www.st.com/resource/en/reference_manual/rm0383-stm32f411xce-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

Retrieved Rev 4, May 2025, 842 pages. RCC, GPIO, general-purpose timers, USART and SPI register behavior. The code explicitly sets a nominal 16 MHz HSI clock with undivided buses.

S3 · STMicroelectronics · STM32F411 device datasheethttps://www.st.com/resource/en/datasheet/stm32f411re.pdf

Pin alternate-function mapping and electrical specifications. Do not generalize selected 5 V-tolerant pin classifications to all pins or operating conditions.

N1 · NXP · UM10204 I²C bus specificationhttps://cache.nxp.com/docs/en/user-guide/UM10204.pdf

Primary protocol reference for START/STOP, acknowledgment, open-drain behavior, timing and pull-up design. Board and target-specific electrical requirements still apply.

E1 · Espressif · ESP32-S3-MINI-1 module datasheethttps://documentation.espressif.com/esp32-s3-mini-1_mini-1u_datasheet_en.html

Module capabilities, pin definitions and electrical limits. A module datasheet does not replace the UNO board’s routing and bridge-firmware documentation.

End of the guide · 100 chapters · 14 complete practice programs · Original SVG illustrations and interactive teaching models. This file contains no analytics, external scripts, network requests or credential fields.