I should really like I2C more than I do. In principle, it’s a brilliant protocol, and in comparison to asynchronous serial and SPI, it’s very well defined and clearly standardized. On paper, up to 127 devices can be connected together using just two wires (and ground). There’s an allowance for multiple clock-masters on the same bus, and a way for slaves to signal that the master to wait. It sounds perfect.
In reality, the tradeoff for using only two wires is a significantly complicated signalling and addressing system that brings both pitfalls and opportunities for debugging. Although I2C does reduce the number of signal wires you need, it gets dangerous when you have more than a handful of devices on the same pair of wires, and you’re lucky when they all conform to the same standard. I’ve never seen twenty devices on a bus, much less 127.
But still, I2C has its place. I2C was designed to connect up a bunch of slower, cheaper devices without using a lot of copper real estate compared to its closest rival protocol: SPI. If you need to connect a few cheap temperature sensors to a microcontroller (and their bus addresses don’t clash) I2C is a great choice. So here’s a guide to making it work when it’s not working.
Continue reading “What Could Go Wrong? I2C Edition”
Serial Peripheral Interface (SPI) is not really a protocol, but more of a general idea. It’s the bare-minimum way to transfer a lot of data between two chips as quickly as possible, and for that reason alone, it’s one of my favorites. But that doesn’t mean that everything is hugs and daffodils. Even despite SPI’s simplicity, there are still a few ways that things can go wrong.
In the previous article in this series, inspired by actual reader questions, I looked into troubleshooting asynchronous serial connections. Now that you’ve got that working, it’s time to step up to debugging your SPI bus! After a brief overview of the system, we’ll get into how to diagnose SPI, and how to fix it.
Continue reading “What Could Go Wrong: SPI”
It’s the easiest thing in the world — simple, straightforward serial data. It’s the fallback communication protocol for nearly every embedded system out there, and so it’s one that you really want to work when the chips are down. And yet! When you need it most, you may discover that even asynchronous serial can cost you a few hours of debugging time and add a few gray hairs to your scalp.
In this article, I’m going to cover most (all?) of the things that can go wrong with asynchronous serial protocols, and how to diagnose and debug this most useful of data transfer methods. The goal is to make you aware enough of what can go wrong that when it does, you’ll troubleshoot it systematically in a few minutes instead of wasting a few hours.
Continue reading “What Could Go Wrong: Asynchronous Serial Edition”
As technology advances, finding the culprit in a malfunctioning device has become somewhat more difficult. As an example, troubleshooting an AM radio is pretty straightforward. There are two basic strategies. First, you can inject a signal in until you can hear it. Then you work backwards to find the stage that is bad. The other way is to trace a signal using a signal tracer or an oscilloscope. When the signal is gone, you’ve found the bad stage. Of course, you still need to figure out what’s wrong with the stage, but that’s usually one or two transistors (or tubes) and a handful of components.
A common signal injector was often a square wave generator that would generate audio frequencies and radio frequency harmonics. It was common to inject at the volume control (easy to find) to determine if the problem was in the RF or audio sections first. If you heard a buzz, you worked backwards into the RF stages. No buzz indicated an audio section problem.
A signal tracer was nothing more than an audio amplifier with a diode demodulator. Starting at the volume control was still a good idea. If you heard radio stations through the signal tracer, the RF section was fine. Television knocked radio off of its pedestal as the primary form of information and entertainment in most households, and thus the TV repair industry was created.
Continue reading “Retrotechtacular: TV Troubleshooting”
Including a live technical demonstration as part of a presentation is a lot like walking a tightrope without a net. Which isn’t to say that we don’t do it — we just keep our fingers crossed and bring our lucky horseshoe. The demo gods have smote [Quinn] a mighty blow, in front of a class at Stanford, no less.
[Quinn]’s scratch-built computer, Veronica, failed to boot in front of a hall of eager students. When the pressure was off, in the comfort of her own lab, [Quinn] got to debugging. You should read her blog post if you’re at all interested in retrocomputing or troubleshooting of low-level hardware bugs. But if you just can’t spare the five minutes for a pleasant read, here’s a spoiler: watch out for flaky card-edge connectors. All’s well that ends well, with a game of pong.
We’ve been following Veronica from her very first clock cycles, so we’re happy to see her back on her feet again. Good job, [Quinn]!
[psgarcha] took a year-old Arduino Uno on an international trip and upon returning found something was wrong. Every time he would try to upload, he would get the dreaded avrdude error, ‘stk500_getsync(): not in sync resp=0x00’. The Rx light would blink a few times during the attempted upload, but the tx light did not. Somehow, something was terribly wrong with the ‘duino, and [psgarcha] dug deep to figure out why.
To test the quality of the Arduino’s serial connection, [psgarcha] performed a loopback test; basically a wire plugged into the Tx and Rx pins of the Arduino. Sending a short message through the serial port showed the problem wasn’t the USB cable, the ATmega16u2 on the ‘duino, or any traces on the board. This would require more thought.
The main reason for the error would then be no communication between the computer and the ‘duino, the wrong COM port selected, the wrong board selected in the Arduino text editor, or timing errors or a corrupt bootloader. The first three errors were now out of the question, leaving timing errors and a corrupt bootloader. Troubleshooting then moved on to ordering a new programmer, and still this didn’t work with the broken Uno.
Frustrated with one of the greatest failures to become an Arduino tinkerer, [psgarcha] took a good, long look at the Uno board. He glanced over to an Arduino Mega board. Something looked different. On the Uno, the resonator had blown off. Problem found, at least.
Replacing the blown part with a hilariously large can crystal oscillator, [psgarcha] was back in business. This isn’t how you would fix 99% of getsync() errors, and it’s difficult imagining a situation where a this part would randomly blow, but if you’re ever looking at a nearly intractable problem, you need to start looking at what really shouldn’t fail.
Awesome rework, though.
[Alan Wolke] aka [w2aew] was challenged to repair a friends Yaesu FT-7800 ham radio. This radio operates on two ham bands, 2 m VHF and 70 cm UHF. The complaint was that the 2 m side was not working but the 70 cm was transmitting fine. Alan started by verifying the complaint using a Bird watt meter with a 50 watt slug and terminating the signal into a 50 W dummy load. [Allen’s] bird meter is the type that has an RF sampler that can be connected to an oscilloscope for added signal viewing and validation.
After verifying that the radio was not working as described, Alan starts by glancing over the circuit board to look for any obvious damage. He then walks us through a block diagram as well as a circuit diagram of the FT-7800 radio before stepping us through the troubleshooting and diagnostics of radio repair. Even when he realizes he might have found the problem he still steps us through the remainder of his diagnostics. The skills and knowledge that Alan shares is extremely valuable to anybody looking to repair radios.
Spoiler alert. At the end of the first video he determines that the pin diodes near the final VHF output were bad. In the second video he reveals that he could no longer source these bad components. Through some clever evaluation of a more current Yaesu radio, [Allen] was able to find suitable replacement components. Lesson two ends with some surface mount solder rework tips as well as testing that the repair was successful.
And just in case you don’t know what a pin diode is, or is used for, Alan shares a third video covering just what this component is and does in a radio. You can follow the jump to watch all three videos.
Continue reading “Diagnose and Repair a Yaesu FT-7800 Ham Radio”