Hands hold a set of white, 3D printed connectors above a wooden table. They look like a cross between a ballpoint pen tip and a spider. The shorter one on the right has yellow, green, black, purple, and white wires coming out the top.

SWD Interface Simplifies Debugging

The proliferation of microcontrollers has made it easier than ever to add some smarts to a project, but sometimes there just isn’t enough space for headers on a board, or you feel a little silly soldering something that will get used to flash a program then languish inside your build. [Dima] wanted to make his boards easier to flash, and developed a PCB footprint and flashing tool pair that makes use of the mounting holes on his boards.

While some debugging tools might use a clamp or tape, [Dima] discovered that using sprung pins only on one side of the connector wedged his fixed locator pin (originally a 1 mm drill bit) into the hole removing the need for any other holding mechanism.

His original prototype worked so well that it took him some time to get back around to making a more reproducible design that didn’t involve fine soldering and superglue. After enlarging the contact pads and several iterations of 3D printing, he developed an interface connector that uses standard jumper wires and a steel rod to provide a sturdy and reliable connection for flashing boards with the corresponding footprint. He’s currently a little disappointed with the overall size of the connector though, and is soliciting feedback on how to make it smaller.

While [Dima]’s MCU of choice is the STM32, but this design should be applicable to any other microcontrollers using a five wire system, or you could take one off for USB. Having trouble finding the SWD points on an existing device? Try this method.

Thanks to [DjBiohazard] for the tip!

Continue reading “SWD Interface Simplifies Debugging”

Single-Stepping The 6502 Processor

Although marketing folk and laypeople may credit [Steve Jobs] as the man behind the success of Apple, those in the tech world know the real truth that without [Steve Wozniak] nothing would have ever gotten off the ground during the early days of the computer company. As an exhibit of his deep knowledge of the machines he was building, take a look at this recreation of a circuit by [Anders] which allows the 6502 processor to step through instructions one at a time, originally designed by [Woz] himself, even though there are still myths floating around the Internet that this type of circuit can’t work.

Like a lot of Internet myths, though, there’s a kernel of truth at the middle. The original 6502 from the mid-70s had dynamic registers, meaning they would lose their values if the chip was run below a critical clock speed. Since single-stepping the processor is much lower than this speed, it seems logical that this might corrupt the data in the registers. But if the clock is maintained to the registers the processor can be halted after each instruction, allowing even the original 6502 to go through its instructions one at a time.

[Anders]’s project sets up this circuit originally laid out by [Steve Wozniak] but updates it a bit for the modern times. Since the technology of the era would have been TTL, modern CMOS logic requires pull-up resistors to keep any inputs from floating. The key design of the original circuit is a set of flip-flops which latch the information on the data bus, and a switch that can be pressed to let the processor grab its next instruction, as well as a set of LEDs that allow the user to see the value on the data bus directly.

Of course, a computer processor of this era would be at a major handicap without a way to debug code that it was running, so there are even dedicated pins that allow this functionality to occur. Perhaps the Internet myth is a bit overblown for that reason alone, but [Anders] is no stranger to the 6502 and has developed many other projects that demonstrate his mastery of the platform.

Continue reading “Single-Stepping The 6502 Processor”

Spying On The ESP32’s GPIO

The ESP32 has been a go-to microcontroller platform for a while now, thanks to its versatile capabilities, integrated Wi-Fi and Bluetooth connectivity, and low power consumption. It’s ideal for a wide range of projects especially those revolving around IoT, partially because of all of the libraries and tools available for it now. The latest tool from [The Last Outpost Workshop] adds a feature we didn’t know we wanted until now: a webserver showing real-time updates of what all of the GPIO pins are doing.

The live GPIO pin monitoring library sets up the ESP32 to stream information about what all of the pins are doing in real time to a webserver, which displays the information as a helpful graphic. The demonstration in the video below shows and example troubleshooting a situation where the code is correct but there’s a mistake in the wiring, helping to quickly identify the problem and hopefully eliminating a wild goose chase for a bug in the software. The library can be quickly installed using the Arduino IDE and only requires the use of one other library and a few lines of code to get everything up and running.

As far as a debugging tool goes, something like this could save a lot of us a significant amount of time, especially with how easy it is to set up. A real-time look into the pins and their behavior, including those set up for PWM, is invaluable for plenty of situations. Of course if you’re building something like a real-time operating system that needs responses within a very specific interval you may want to look at more in-depth strategies for probing the GPIO.

Thanks to [Bob] for the tip!

Continue reading “Spying On The ESP32’s GPIO”

Hacker Tactic: Internal ESD Diode Probing

Humans are walking high voltage generators, due to all the friction with our surroundings, wide variety of synthetic clothes, and the overall ever-present static charges. Our electronics are sensitive to electrostatic discharge (ESD), and often they’re sensitive in a way most infuriating – causing spurious errors and lockups. Is there a wacky error in your design that will repeat in the next batch, or did you just accidentally zap a GPIO? You wouldn’t know until you meticulously check the design, or maybe it’s possible for you to grab another board.

Thankfully, in modern-day Western climates and with modern tech, you are not likely to encounter ESD-caused problems, but they were way more prominent back in the day. For instance, older hackers will have stories of how FETs were more sensitive, and touching the gate pin mindlessly could kill the FET you’re working with. Now, we’ve fixed this problem, in large part because we have added ESD-protective diodes inside the active components most affected.

These diodes don’t just help against ESD – they’re a general safety measure for protecting IC and transistor pins, and they also might help avoid damaging IC pins if you mix. They also might lead to funny and unexpected results, like parts of your circuit powering when you don’t expect them to! However, there’s an awesome thing that not that many hackers know — they let you debug and repair your circuits in a way you might not have imagined.

Continue reading “Hacker Tactic: Internal ESD Diode Probing”

This Arduino Debugger Uses The CH552

One of the things missing from the “classic” Arduino experience is debugging. That’s a shame, too, because the chips used have that capability. However, the latest IDE has the ability to work with external debuggers and if you want to get started with a classic ATMega Arduino, [deqing] shows you how to get started with a cheap CH552 8-bit USB microcontroller board as the debugging dongle.

The CH552 board in question is a good choice, primarily because it is dirt cheap. There are design files on GitHub (and the firmware), but you could probably pull the same trick with any of the available CH552 breakout boards.

Continue reading “This Arduino Debugger Uses The CH552”

A schematic for a continuity tester that modulates its pitch based on the resistance measured

Op Amp Contest: Clever Continuity Tester Tells You Where The Problem Is

A continuity tester, as found on most multimeters today, is a great tool for finding broken connections and short circuits. But once you’ve found a short, it’s up to you to figure out which part of the circuit it’s in – a tedious job on a large PCB with hundreds of components. [John Guy] aims to ease this task with a continuity tester that modulates the beeper’s tone according to the resistance measured in the circuit. Tracking down a short circuit is then simply a matter of probing multiple points along a track and observing whether the pitch goes up or down.

The circuit is based on a single AD8534 quad op amp chip. The first stage measures the voltage across the circuit under test in response to small current and amplifies it. The resulting signal is fed into a voltage-controlled oscillator (VCO) made from one op amp connected as an integrator and another working as a comparator with hysteresis. Op amp number four amplifies the resulting square wave and drives a speaker. A low-pass filter makes the sound a bit more pleasing to the ears by removing the higher notes.

[John] paid particular attention to the PCB design to make it easy to assemble despite having a large number of SMD components on a small board. He even placed a parts list on the rear silkscreen, so anyone can assemble it even without the accompanying documents. The resulting board can be placed in a laser-cut acrylic case, turning it into a neat handheld instrument that will definitely find a place in any engineer’s toolbox. Measuring resistance through sound is not as accurate as using a full four-wire setup with an ohmmeter, but will be much faster and easier if you just want to find that annoying solder bridge hiding somewhere on your board.

Debugging And Analyzing Real-Mode 16-Bit X86 Code With Fresh Bread

Running a debugger like gdb with real-mode 16-bit code on the x86 platform is not the easiest thing to do, but incredibly useful when it comes to analyzing BIOS firmware and DOS software. Although it’s possible to analyze a BIOS image after running it through a disassembler, there is a lot that can only be done when the software is running on the real hardware. This is where [Davidson Francis] decided that some BREAD would be useful, as in BIOS Reverse Engineering & Advanced Debugging.

What BREAD does is provide some injectable code that with e.g. a BIOS replaces the normal boot logo with the debugger stub. This stub communicates with a bridge via the serial port, with the gdb client connecting to this bridge. Since DOS programs are also often 16-bit real-mode, these can be similarly modified to provide light-weight in-situ debugging and analysis. We imagine that this software can be very useful both for software archaeology and embedded purposes.

Thanks to [Rodrigo Laneth] for the tip.