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

March 28, 2023 by Maya Posch 7 Comments

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.

A closeup picture showing the jagged edge of the cut

Debugging Laser Cut Wobble, The Scientific Way

December 29, 2022 by Arya Voronova 23 Comments

[PWalsh] was using his lasercutter to cut acrylic, expecting the cuts to have a pleasantly smooth edge. Alas, the edges turned out to be wobbly and sandpaper-like, not smooth in the slightnest. Bummer! Internet suggested a stepper motor swap, but not much in the way of insights – and that would’ve been a royal pain for sure. How would you approach debugging such a problem? Well, [PWalsh] didn’t want to swap crucial components willy-nilly, going the scientific way instead, and breaks it down for us.

Having compiled an extensive list of possible places to look for a fault in, he started going through fundamental assumptions. Do other lasercutters experience this issue? No, even the cheap ones can cut things properly. Is it water level causing intermittent cooling? Nope, not that. Is it the stepping settings? Tweaked, not that. Laser pulsing frequency? No dice. Continue reading “Debugging Laser Cut Wobble, The Scientific Way” →

A PCB with several points highlighted by a projection system

Augmented Reality Workbench Helps You To Debug Your Boards

November 18, 2022 by Robin Kearey 17 Comments

No matter how advanced your design skills, the chances are you’ll need to spend some time chasing bugs in your boards after they come back from the assembly house. Testing and debugging a PCB typically involves a lot of cross-checking between the board, the layout and the schematic, which quickly becomes tiresome even for mildly complex designs. To make this task a bit easier, [Ishan Chatterjee] and colleagues at the University of Washington have designed the Augmented Reality Debugging Workbench, or ARDW for short.

The ARDW is a setup consisting of a lab workbench with an antistatic mat, a selection of measurement instruments and a PC. You can simply place your board on the bench, open the schematic and layout in KiCAD and start measuring and debugging your design as you normally would, but the real magic happens when you select a new icon in KiCAD that exports the schematic and layout to the ARDW system. From that moment, you can select components in your schematic and have them highlighted not only on the layout, but on the physical board in front of you as well. This is perhaps best demonstrated visually, as the team members do in the video embedded below.

The real-life highlighting of components is achieved thanks to a set of cameras that track the motion of everything on the desk as well as a video projector that overlays information on top of the PCB. All of this enables a variety of useful debugging features: for example, there’s an option to highlight pin one on all components, enabling a simple visual check of each component’s orientation. You can select all Do Not Populate (DNP) instances and immediately see if all highlighted pads are empty. If you’re not sure which component you’re looking at, just point at it with your multimeter probe and it’s highlighted on the schematic and layout. You can even place your probes on a net and automatically log the voltage for future reference, thanks to a digital link between the multimeter and the ARDW software.

In addition to designing and building the ARDW, the team also performed a usability study using a group of human test subjects. They especially liked the ability to quickly locate components on crowded boards, but found the on-line measurement system a bit cumbersome due to its limited positional accuracy. Future work will therefore focus on improving the resolution of the projected image and generally making the system more compact and robust. All software is freely available on the project’s GitHub page, and while the current system looks a little complex for hobbyist use, we can already imagine it being a useful tool in production environments.

It’s not even the first time augmented reality has been used for PCB debugging: we saw a somewhat similar system at the 2019 Hackaday Superconference. AR can also come in handy during the design and prototyping phase, as demonstrated by this AR breadboard.

Continue reading “Augmented Reality Workbench Helps You To Debug Your Boards” →

The Orbtrace debugger hardware connected to a development board t hrough a 20-pin ribbon cable. The development board has a green LED shining.

ORBTrace Effort: Open Tool For Professional Debugging

July 26, 2022 by Arya Voronova 35 Comments

There are some fairly powerful debugging facilities available on today’s microcontrollers — if your code crashes mysteriously, chances are, there’s a debugging interface that could let you track down the exact crash circumstances in no time. Sadly, debugging tools for these powerful interfaces tend to be prohibitively expensive and highly proprietary, thus, not friendly for hobbyists. Now, there’s a community-driven high-capability debugging platform called ORBTrace, brought to us by [mubes] and [zyp].

With parallel trace, you get a constant stream of consciousness, every exact instruction executed by your CPU. [mubes] and [zyp] set out to tap into the power of parallel trace debugging for Cortex-M processors. and the ORBTrace project was born. Relying on the Orbuculum project’s software capabilities, this FPGA-based debugger platform can do parallel trace and the more popular high-speed SWO trace – and way more. ORBTrace has the potential to grow into a powerful debug helper tool, with enough capabilities for anyone to benefit. And of course, it’s fully open-source.

The ORBTrace platform has plenty of untapped potential. There’s the battle-tested JTAG and SWD that you can already use with all the open tools you could expect. However, there’s also plenty of available resources on the FPGA, including even a currently unutilized RISC-V softcore. If you wanted to add support for any other family of devices to this debugger, sky’s the limit! And, of course, there’s cool software to go with it – for example, orbmortem, which keeps a ring buffer of instructions in memory and shows you the last code executed before your CPU stops, or orbstat, a tool for profiling your embedded code.

If you’re looking to purchase effortless feature parity with Segger or Lauterbach devices, the ORBTrace doesn’t promise that. Instead, it’s an open debugging toolkit project, with hardware available for purchase, and software just waiting for you take control of it. This project’s community hangs out in the 1BitSquared discord’s #orbuculum channel, and gateware’s advancing at a rapid pace – welcoming you to join in on the fun.

ORBTrace is a powerful tool for when your goals become large and your problems become complex. And, being a community-driven experimental effort, we’ll undoubtedly see great things come out of it – like the Mooltipass project, originally developed by Hackaday community members, and still going strong.

Linux Fu: Up Your GDB Game!

June 14, 2022 by Al Williams 19 Comments

If you want to buy a car, there are plenty of choices. If you want to buy a jetliner, there are fewer choices. If you want to use the Large Hadron Collider, you have a choice of exactly one. The harder something is to create, the less likely there is to be many of them. If you are looking for a Linux debugger, there are only a few choices, but gdb is certainly the one you will find most often. There is lldb and a handful of non-open commercial offerings, but for the most part you will use gdb to debug software on Linux.

Of course, not everyone’s a fan of gdb’s text-based interface, so there’s no shortage of front ends available for it. In fact, gdb has two potentially built-in interfaces although depending on how you install gdb, you might not have both of them. Of course, if you use an IDE, it very likely is a front end for gdb among other things. But at the core is gdb and — usually — there is a window somewhere that you can stuff gdb commands into. Even emacs — which might be considered the original IDE — can run gdb and gives you a sort-of GUI experience.

Continue reading “Linux Fu: Up Your GDB Game!” →

Screenshot of a logic analyzer software, showing the SDA channel being split into three separate traces

I2C Tap Helps Assign Blame For SDA Conflicts

May 2, 2022 by Arya Voronova 8 Comments

If you’ve ever debugged a misbehaving I2C circuit, you probably know how frustrating it can be. Thankfully [Jim] over at Hackaday.io, has a proto-boardable circuit that can help!

Inter-integrated circuit bus (aka I2C) uses open collector outputs on a two wire interface. Open collector means a device connected to the I2C bus can only pull the bus down to ground. Chips never drive a logic “HIGH” on the wires. When nothing is driving the lines low, a weak resistor pulls the lines up to VCC. This is a good thing, because I2C is also a multidrop bus — meaning many devices can be connected to the bus at the time. Without open collector outputs, one chip could drive a high, while another drives a low – which would create a short circuit, possibly damaging both devices.

Even with all this protection, there can be problems. The SCL and SDA lines in the I2C communication protocol are bidirectional, which means either a controller or a peripheral can pull it low. Sometimes, when tracing I2C communications you’ll need to figure out which part is holding the line low. With many devices sharing the same bus, that can become nigh-impossible. Some folks have tricks with resistors and analog sampling, but the tried and true method of de-soldering and physically lifting chip pins off the bus often comes into play.

[Jim’s] circuit splits SDA signal into controller-side and peripheral-side, helping you make it clear who is to blame for hiccups and stray noise. To do that, he’s using 6N137 optoisolators and LMV393 comparators. [Jim] shared a NapkinCAD schematic with us, meant to be replicate-able in times of dire need. With this design, you can split your I2C bus into four separate channels – controller-side SDA, peripheral-side SDA, combined SDA and SCL. 4 Channels might be a lot for a scope, but this is no problem for today’s cheap logic analyzers.

Continue reading “I2C Tap Helps Assign Blame For SDA Conflicts” →

Hacked GDB Dashboard Puts It All On Display

March 22, 2022 by Al Williams 20 Comments

Not everyone is a fan of GUI interfaces. But some tasks really lend themselves to something over a bare command line. Very few people enjoy old command line text editors like edlin or ed. Debugging is another task where showing source files and variables at all times makes sense. Of course, you don’t absolutely have to have a GUI per se. You can also use a Text User Interface (TUI). In fact, you can build gdb — the GNU Debugger — with a built-in TUI mode. Try adding –tui to your gdb command line and see what happens. There are also many GUI frontends for gdb, but [cyrus-and] has an easy way to get a very useful TUI-like interface to gdb that doesn’t require rebuilding gdb or even hacking its internals in any way.

The secret? The gdb program runs a .gdbinit file on startup. By using Python and some gdb commands, [cyrus-and] causes the debugger to have a nice dashboard interface for your debugging sessions. If you install a helper script, you can even get syntax highlighting.

The system uses modules and you can even add your own custom modules and commands, if you like. You can also control what modules appear on each dashboard display. Normally, the dashboard shows when the program stops. For example, on each breakpoint. However, gdb has a hook system that allows you to trigger a dashboard using the appropriately-named dashboard command on other commands, too. Using the layout option to the dashboard command, you can even trigger different modules at different times.

Installation is simple. Just put the .gdbinit file in your home directory. If you want syntax highlights, you need to install Pygments, too. We understand you can even use his under Windows, if you like.

We don’t always take full advantage, but gdb is actually amazing. The flexible architecture makes all sorts of interesting things possible.