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.

Customisable Micro-Coded Controller Helps With In-Circuit Debugging

December 30, 2021 by Dave Rowntree No comments

Over on Hackaday.io, [Zoltan Pekic] has been busy building a stack of tools for assisting with verifying and debugging retro computing applications. He presents his take on using Intel hex files for customised in-circuit testing, which is based upon simple microcoded sequencers, which are generated automatically from a high level description.

The idea is that it is very useful to be able to use an FPGA development board to emulate the memory bus component of the CPU, allowing direct memory access for design validation purposes. This approach will also allow the production of a test rig to perform board level verification. The microcode compiler (MCC) generates all the VHDL, and support files needed to target a Xilinx FPGA based dev board, but is generic enough to enable targeting other platforms with a little adaptation.

Another interesting use case enables in-circuit tracing of buggy memory accesses, with the microcode sequencer decoding the accesses and dumping the relevant information out to either a serial port, or even direct to an embedded VGA controller, hardware allowing.

This automated approach to generating customisable microcoded hardware is a very nice trick to have in your bag, and even if it only helps in certain circumstances, [Zoltan] notes that it at least serves as an interesting example of the architecture of computers from history, if not much else.

Source for the example 8085 project can be found on the project GitHub, and the toolchain source can found here also.

For an interesting practical use of microding to implement emulations of historical hardware, checkout this neat switchable reproduction calculator project.

QB64 Hits Version 2.0, Gets Enhanced Debugging

October 17, 2021 by Tom Nardi 28 Comments

Despite the name, BASIC isn’t exactly a language recommended for beginners these days. Technology has moved on, and now most people would steer you towards Python if you wanted to get your feet wet with software development. But for those who got their first taste of programming by copying lines of BASIC out of a computer magazine, the language still holds a certain nostalgic appeal.

If that sounds like you, then may we heartily recommend QB64. The open source project seeks to modernize the classic programming language while retaining compatibility for QBasic 4.5, the late-80s BASIC environment Microsoft included with MS-DOS. That modernization not only includes the addition of contemporary technology like OpenGL, but cross-platform support that lets you run the same code on Windows, Linux, and Mac OS.

The QB64 team released version 2.0 just a few days ago, making this the perfect time to give the project a test drive if you haven’t tried it out yet. The changelog includes platform specific improvements for each supported operating system, as well as a long list of general fixes and updates. But arguably the biggest feature for this release is the inclusion of the $Debug metacommand.

When this command is included in your code, the IDE will insert a debugging stub into the compiled program. During execution, the QB64 IDE will switch over to debugging mode, and communicate with your program in real-time over a local TCP/IP connection. The debugging mode lets you step through the code line-by-line, check the values of variables, and set breakpoints. Once you’re done fussing with the code and want to release a final binary, you just need to remove that single $Debug command and recompile.

We’ve talked in the past about using QB64 to revitalize vintage code, and think the project is a fantastic melding of old and new technology. You never know when you might suddenly have the urge to dust off some code you wrote back in the 80s and run it on an OS that didn’t even exist at the time.