Given an unknown PCBA with an ARM processor, odds are good that it will have either the standard 10 pin 0.05″ or 20 pin 0.1″ debug connector. This uncommon commonality is a boon for an exploring hacker, but when designing a board such headers require board space in the design and more components to be installed to plug in. The literally-named Debug Edge standard is a new libre attempt to remedy this inconvenience.
The name “Debug Edge” says it all. It’s a debug, edge connector. A connector for the edge of a PCBA to break out debug signals. Card edge connectors are nothing new but they typically either slot one PCBA perpendicularly into another (as in a PCI card) or hold them in parallel (as in a mini PCIe card or an m.2 SSD). The DebugEdge connector is more like a PCBA butt splice.
It makes use of a specific family of AVX open ended card edge connectors designed to splice together long rectangular PCBAs used for lighting end to end. These are available in single quantities starting as low as $0.85 (part number for the design shown here is 009159010061916). The vision of the DebugEdge standard is that this connector is exposed along the edge of the target device, then “spliced” into the debug connector for target power and debug.
Right now the DebugEdge exists primarily as a standard, a set of KiCAD footprints, and prototype adapter boards on OSHPark (debugger side, target side). A device making use of it would integrate the target side and the developer would use the debugger side to connect. The standard specifies 4, 6, 8, and 10 pin varieties (mapping to sizes of available connector, the ‘010’ in the number above specifies pincount) offering increasing levels of connectivity up to a complete 1:1 mapping of the standard 10 pin ARM connector. Keep in mind the connectors are double sided, so the 4 pin version is a miniscule 4mm x 4.5mm! We’re excited to see that worm its way into a tiny project or two.
We’ve seen plenty of part-free debug and programming connectors before. Have a favorite? Let us know in the comments!
Congratulations, you have just finished assembling your electronics project. After checking for obvious problems you apply power and… it didn’t do what you wanted. They almost never work on the first try, and thus we step into the world of electronics debugging with Daniel Samarin as our guide at Hackaday Superconference 2019. The newly published talk video embedded below.
Beginners venturing just beyond blinking LEDs and premade kits would benefit the most from information here, but there are tidbits useful for more experienced veterans as well. The emphasis is on understanding what is actually happening inside the circuit, which explains the title of the talk: Debugging Electronics: You Can’t Handle the Ground Truth! So we can compare observed behavior against designed intent. Without an accurate understanding, any attempted fix is doomed to failure.
To be come really good at this, you need to embrace the tools that are often found on a well stocked electronics bench. Daniel dives into the tricks of the trade that transcend printf and blinking LED to form a plan to approach any debugging task.
Continue reading “Debugging Electronics: To Know Why It Didn’t Work, First Find What It Is Actually Doing”
When a processor has a fault it can leave what looks to be precious little in the way of cause and effect. Debug-by-print-statement works surprisingly well in simple cases, but where in a desktop environment you would drop into a debugger to solve trickier problems this can be an onerous task on an embedded system. [Ross Schlaikjer]’s excellent blog post walks through setting up one of our favorite Open Hardware debug probes and shows us that with the right tooling in place, unexpected faults aren’t quite so impenetrable. Continue reading “Debug Superpowers Bring An STM32 Back From The Dead”
If you upgraded to Amazon’s latest Echo Dot, you might have been surprised to find that the diminutive voice assistant had shed its USB port. Earlier models of the Dot used a garden variety micro USB port for power, which hackers eventually figured out also provided a helpful way to snoop around inside the device’s firmware. The fact that the USB port was deleted on the latest Echo Dot in favor of a simple barrel connector for power was seen by some as a sign that Amazon was trying to keep curious owners out of their hardware.
But as [Brian Dorey] shows, all they did was put a bump in the road. While they removed the external USB connector, the traces for it are still on the board waiting to be accessed. Even better, it turns out the USB data lines are connected to the test points located on the bottom of the Dot. All you need is a simple breakout that will connect through the existing opening in the device’s case, and you’ve got your USB port back.
So what can you do with USB on the Echo Dot? Well, not much right now. [Brian] found that the Dot shows up as a Mediatek device under Linux using
fastboot can see it and even confirms the presence of a locked bootloader. It’s going to take some work from the community to see how deep this particular rabbit hole goes.
Even if you’re not interested in restoring its USB port, [Brian] has uncovered a wealth of fascinating hardware information about the Echo Dot during his deep-dive. He’s mapped out many of the test points located throughout the device’s PCBs, and found a few interesting points that might be worth further investigation. For example, he found that driving one of the pins high would trigger the Dot to mute its microphones; which could be useful for anyone looking to cover Alexa’s ears.
[Brian] first cracked open the Echo Dot last month, after scoring one for cheap during Amazon’s Prime Day sale. It looks like he’s making fairly rapid progress on unraveling the mysteries of this popular gadget, and we’re very interested in seeing where this research takes us.
We’ve all been there. When debugging a microcontroller project, we just want to put in a print statement to figure out what’s going on with the microcontroller in real time. However, advanced embedded programmers know that printf statements are verboten: they’re just too SLOW. While not fixing this plight entirely, [Atakan Sarioglu] has come up with a clever way to create readable debug messages with minimal runtime overhead.
[Atakan Sarioglu]’s innovation, called BigBug (Github), is a dynamically-generated codebook. The codebook translates abbreviated messages sent over serial (UART here) to longer-form human-readable messages. To generate the codebook, BigBug automatically parses your comments to create a lookup between an abbreviation and the long-form message. When you are running your program on the microcontroller, BigBug will translate the short codes to long messages in real-time as you send log/debug data over serial. Continue reading ““DB” = Abbreviated Microcontroller Debugging”
Originally released on the Nintendo 64 in 2001, Animal Crossing was the first entry into what has become a massively successful franchise. But while the game has appeared on more modern Nintendo consoles, most recently Android and iOS, the version released on the GameCube holds a special place in many fan’s hearts. The GameCube version was the first time those outside of Japan got a taste of the unique community simulation offered by Animal Crossing, and maintains a following nearly 20 years after its release.
[James Chambers] has recently been investigating creating mods for the GameCube version of Animal Crossing, and in the process uncovered some interesting references to a debug mode. That launched a deep dive into the game’s assembly code in an attempt to find what the debug functions did and if they could be enabled without having to patch the game ROM. In the end, he was able to find a push button code that enables debug mode on the retail copy of the game.
[James] starts by using the debugger provided by the Dolphin GameCube emulator to poke around and figure out exactly what flags need to be modified to activate the debug mode. This leads to a few interesting finds, such as being able to pop up a performance monitor graph and some build info. Eventually he finds the proper incantation to bring up a functional debug display in the game, but there was still the mystery of how you do it on the real hardware with a retail copy of the game.
It wouldn’t be unreasonable to think that some special dongle or development version of the GameCube would be required to kick the game into debug mode. But through careful examination of the code path, [James] was able to figure out that hitting a specific combination of buttons on the controller was all that was required to use the debug mode on the stock game. Once the debug mode is started, a controller plugged into the second port allows the user to navigate through options and perform tasks. Not everything is currently understood, but some progress has been made, such as figuring out how to add items to your inventory.
It’s hardly Nintendo’s most popular console, but there’s still a healthy interest in GameCube hacking as the machine approaches its 20th anniversary. We recently saw some impressive work being done to reverse engineer the system’s wireless controllers, though some people are more interested in just cutting the thing in half.
[Thanks to Tim Trzepacz for the tip.]
Anyone who slings code for a living knows the feeling all too well: your code is running fine and dandy one minute, and the next minute is throwing exceptions. You’d swear on a stack of O’Reilly books that you didn’t change anything, but your program stubbornly refuses to agree. Stumped, you turn to the only one who understands you and pour your heart out to a little yellow rubber duck.
When it comes to debugging tools, this digital replacement for the duck on your desk might be even more helpful. Rubber duck decoding, where actually explaining aloud to an inanimate object how you think the code should run, really works. It’s basically a way to get you to see the mistake you made by explaining it to yourself; the duck or whatever – personally, I use a stuffed pig– is just along for the ride. [platisd] took the idea a step further and made his debugging buddy, which he dubs the “Dialectic Ball,” in the form of a Magic 8-Ball fortune teller. A 3D-printed shell has an ATtiny84, an accelerometer, and an LCD screen. To use it, you state your problem, shake it, and read the random suggestion that pops up. The list has some obvious suggestions, like adding diagnostic print statements or refactoring. Some tips are more personal, like talking to your local guru or getting a cup of coffee to get things going again. The list can be customized for your way of thinking. If nothing else, it’ll be a conversation piece on your desk.
If you’re more interested in prognostication than debugging, we have no shortage of Magic 8-Ball builds to choose from. Here’s one in a heart, one that fits in a business card, and even one that drops F-bombs.
Continue reading “Rubber Duck Debugging The Digital Way”