SWYoon Labs

Series navigation: Episode 1: The Roadmap · Episode 7: Reading Arduino Pin-Current Specifications · Episode 16 The problem: A wire patch makes Revision A work, but the next board may repeat the same mistake. The goal: Convert symptoms and workarounds into traced design changes and regression tests. The result: A Revision B process that preserves evidence instead of hiding failure. AI-generated illustration of hardware iteration. The boards and defect notes are not artifacts from a physical project. The wire patch worked—so was the board fixed? Revision A would not start reliably. A wire was added, one resistor changed, and the board began working. That is a valuable diagnostic result, but it is not yet a controlled design revision. The patch may create a new antenna, bypass protection, depend on assembly skill, or fix only the one unit on the desk. In software, a quick production patch should eventually become a reviewed source change and regression test. Hardware ne...

Series navigation: Episode 1: The Roadmap · Episode 7: Reading Arduino Pin-Current Specifications · Episode 15 The problem: Connecting full power immediately can turn one assembly error into several damaged parts. The goal: Make first power-on a sequence of reversible tests with stop conditions. The result: A bring-up checklist from visual inspection to firmware and interfaces. AI-generated illustration of preparation for first power-on. No measurement shown is evidence from a real board. I wanted to plug in USB and see the LED blink After waiting for a new PCB, the natural impulse is to connect everything and run the full program. That single action combines too many unknowns: assembly, polarity, shorts, regulators, clocks, reset, programming, firmware, and external devices. If smoke appears, the evidence has already been destroyed. First power-on should be deliberately boring. The objective is not to demonstrate the whole product. It is to discover the first incorr...

Series navigation: Episode 1: The Roadmap · Episode 11 The problem: A 5 V module and a 3.3 V controller have matching signal names, but direct wiring may fail or damage an input. The goal: Check voltage limits and logic thresholds in both directions. The result: A decision process for direct connection, dividers, buffers, and level translators. AI-generated illustration of a mixed-voltage workbench. Verify every connection against the exact device data sheets. The connector fit, so I almost connected it The peripheral board had VCC , GND , TX , and RX . The microcontroller had pins with the same names. One board used 5 V and the other used 3.3 V. Matching names describe functions, not electrical compatibility. Before joining the wires, I needed answers to two separate questions: Will a HIGH output be recognized as HIGH by the receiver? Can the receiver safely tolerate the maximum voltage? Passing the first test does not guarantee the second. Four data-sheet value...

Series navigation: Episode 1: The Roadmap · Episode 9: SPI LCD Debugging · Episode 10 The problem: A button input changes even when nobody presses it. The goal: Give every digital input a defined idle state. The result: A practical wiring and debugging checklist for pull resistors, polarity, noise, and shared ground. AI-generated illustration of a low-voltage GPIO debugging setup; it is not a record of a physical measurement. The button worked—until my hand moved near it I connected a pushbutton to a microcontroller, read the pin, and expected either HIGH or LOW . Instead, the value changed randomly. Touching a wire sometimes changed it again. The code was deterministic. The voltage at the input was not. A digital input is not automatically zero when nothing drives it. Its high impedance makes it easy to sense, but also allows leakage, electric fields, long wires, and switching signals nearby to move the voltage across the logic threshold. This is a floating input ....

Series navigation: Episode 1: The Roadmap · Episode 7: Reading Arduino Pin-Current Specifications · Episode 9 The problem: The LCD backlight turns on, but the screen remains white. The goal: Separate display power from successful SPI communication and initialization. The result: A checklist for SCK, MOSI, MISO, CS, D/C, RESET, voltage, clock mode, and command order. AI-generated illustration of a low-voltage SPI debugging setup. Verify wiring against the exact display-controller data sheet. The backlight was on, so I assumed the LCD was working I connected a color display. It lit immediately, but the entire panel stayed white. The result is misleading. The backlight is often a separate load. It can receive power while the display controller is unpowered, held in reset, never selected, wired incorrectly, or receiving the wrong initialization. A white screen does not mean “SPI is almost working.” It only proves that light passes through the panel. What each wire does...

Series navigation: Episode 1: The Roadmap · Episode 7: Reading Arduino Pin-Current Specifications · Episode 8 The problem: A terminal shows random symbols even though both devices say “UART.” The goal: Understand what must match electrically and logically before bytes become readable text. The result: A debugging order for TX/RX, ground, voltage, baud rate, frame format, buffering, and signal capture. AI-generated illustration of a low-voltage UART bench. It is not a measurement record or exact wiring guide. The terminal opened, but the text looked broken UART is often the first communication interface I use on a board. It prints boot messages, accepts commands, connects two controllers, or talks to a GPS, modem, Bluetooth module, serial display, or USB-to-serial adapter. Then the terminal shows this: text ��H�l� The program may be sending Hello , but UART does not transmit software strings. It places timed voltage levels on a wire. The receiver must agree about vo...