A Usable Arduino Debugging Tool

For as popular as the Arduino platform is, it’s not without its problems. Among those is the fact that most practical debugging is often done by placing various print statements throughout the code and watching for them in the serial monitor. There’s not really a great way of placing breakpoints or stepping through code, either. But this project, known as eye2see, hopes to change that by using the i2c bus found in most Arduinos to provide a more robust set of debugging tools.

The eye2see software is set up to run on an Arduino or other compatible microcontroller, called the “probe”, which is connected to the i2c bus on another Arduino whose code needs to be debugged. Code running on this Arduino, which is part of the eye2see library, allows it to send debugging information to the eye2see probe. With a screen, the probe can act as a much more powerful debugger than would otherwise typically be available, being able to keep track of variables in the main program, setting up breakpoints, and outputting various messages on its screen.

The tool is not without its downsides, though. The library that needs to run on the host Arduino slows down the original program significantly. But for more complex programs, the tradeoff with powerful debugging tools may be worth it until these pieces of code can be removed and the program allowed to run unencumbered. If you’d like to skip needing to use a second Arduino, we’ve seen some other tools available for debugging Arduino code that can run straight from a connected PC instead.

Four jumper wires with white heatshrink on them, labelled VCC, SCL, SDA and GND

Three Pitfalls In I2C Everyone Wishes Weren’t There

The best part of I2C is that it is a bus that is available just about anywhere, covering a vast ecosystem of devices that offer it as a hardware-defined interface, while being uncomplicated enough that it can also be implemented purely in software on plain GPIO pins. Despite this popularity, I2C is one of those famous informal standards that feature a couple of popular implementations, while leaving many of the details such as exact timing, bus capacitance and other tedious details to the poor sod doing the product development. Thus it is that we end up with articles such as a recent one on the tongue-twisting [pair of pared pears] blog, covering issues found while implementing an I2C slave.

As with any shared bus, whether multi-master or not, figuring out when the bus is clear is a fun topic, yet one which can cause endless headaches. One issue here comes from a feature that the SMBus version of I2C calls quick read/write. This allows for the rapid transfer of some data. Still, depending on the data returned by the slave, it may appear to the master that nothing is happening yet, since SDA is being held low by the slave until the stop condition, essentially locking the bus.

I2C hold times example.
I2C hold times example.

Where things get even more exciting comes generally in the form of what logic analyzers love to traumatically call a ‘spurious start/stop condition’. This refers to the behavior of SDA and SCL, with SDA going low before SCL indicating an error. This can occur due to a hold time that’s too low, causing other devices on the bus to miss the transition. Here SMBus defines a transition time of 300 ns, while I2C calls for 0 seconds, but it’s now suggested to delay calling a start/stop condition until a delay of 300 ns has passed. Essentially, it would seem that implementing a hold time is the way forward until evidence to the contrary appears.

The third pitfall pertains to the higher-speed modes of I2C, including Fast-Mode (FM) and Fast-Mode Plus (FM+). Backward compatibility with these higher speed versions is absent to spotty. Although FM+ (introduced by NXP in 2007) is supposed to be backward compatible with slower speeds, effectively the timing requirement differences between the FM+ and FM standards are too large to compensate for. At least in the current versions of the standards, but one of the joys of I2C is that there’s always another new set of revisions to look forward to.

A Simple Guide To Bit Banged I2C On The 6502

We covered [Anders Nielsen]’s 65duino project a short while ago, and now he’s back with an update video showing some more details of bit-banging I2C using plain old 6502 assembly language.

Obviously, with such a simple system, there is no dedicated I2C interface hardware, so the programmer must take care of all the details of the I2C protocol in software, bit-banging it out to the peripheral and reading back the response one bit at a time.

The first detail to concern us will be the I2C addresses of the devices being connected to the bus and how low-level bit manipulation is used to turn the 7-bit I2C address into the byte being bit-banged. As [Anders] shows, setting a bit is simply a logical-OR operation, and resetting a bit is a simple logical-AND operation using the inversion (or one’s complement) bit to reset to form a bitmask. As many will already know, this process is necessary to code for a read or a write I2C operation. A further detail is that I2C uses an open-collector connection scheme, which means that no device on the bus may drive the bus to logical high; instead, they must release the drive by going to the high impedance state, and an external pull-up resistor will pull the bus high. The 6532 RIOT chip (used for I/O on the 65unio) does not have tristate control but instead uses a data direction register (DDR) to allow a pin to be an input. This will do the job just fine, albeit with slightly odd-looking code, until you know what’s going on.

From there, it’s a straightforward matter to write subroutines that generate the I2C start, stop, and NACK conditions that are required to write to the SSD1306-based OLED to get it to do something we can observe. From these basic roots, through higher-level subroutines, a complete OLED library in assembly can be constructed. We shall sit tight and await where [Anders] goes next with this!

We see I2C-connected things all the time, like this neat ATtiny85-based I2C peripheral, and whilst we’re talking about the SSD1306 OLED display controller, here’s a hack that shows just how much you can push your luck with the I2C spec and get some crazy frame rates.

Continue reading “A Simple Guide To Bit Banged I2C On The 6502”

Interlaken Want To Connect All The Chips

One of the problems with designing things on a chip is finding a good way to talk to the outside world. You may not design chips yourself, but you care because you want to connect your circuits — including other chips — to the chips in question. While I2C and SPI are common solutions, today’s circuits are looking for more bandwidth and higher speeds, and that’s where Interlaken comes in. [Comcores] has an interesting post on the technology that blends the best of SPI 4.2 and XAUI.

The interface is serial, as you might expect. It can provide both high-bandwidth and low-latency multi-channel communications. Interlaken was developed by Cisco and Cortina Systems in 2006 and has since been adopted by other industry-leading companies. Its latest generation supports speeds as high as 1.2 Tbps.

Continue reading “Interlaken Want To Connect All The Chips”

Digital Replica Of Antique Weather Monitoring Instrument

Computers and digital sensors have allowed for the collection and aggregation of data barely possible to imagine to anyone in the instrumentation scene even sixty years ago. Before that, things like weather stations, seismometers, level sensors, and basically any other way of gathering real data about the world would have been performed with an analog device recording the information on some sort of spool of paper. This was much more tedious but the one thing going for these types of devices was their aesthetic. [mircemk] is back to bring some of that design inspiration to a digital barometric display.

The barometer is based around an Arduino Arduino Nano and a relatively large I2C display to display the captured data. It also uses a BME 280 pressure sensor board, but the technical details of this project are not the focal point here. Instead, [mircemk] has put his effort in recreating the old analog barographs, which display barometric data on a spool of paper over time, on the I2C display. As the device measures atmospheric pressure, it adds a bar to the graph, displaying the data over time much as the old analog device would have.

We’ve discussed plenty of times around here that old analog meters and instrumentation like this recreation of a VU meter are an excellent way of getting a more antique aesthetic than is typically offered by digital replacements. Adding in a little bit of style to a project like this can go a long way, or you can simply restore the original antique instead.

A modchip described in the article - a small PCB with an epoxy blob on it, soldered to the Cisco switch PCB using four thin wires

Counterfeit Cisco Hardware Bypasses Security Checks With Modchips

Some pictures recently surfaced on social media, showing a small PCB tapped into four points on Cisco-branded boards. What is this about? A NSA backdoor so data can be exfiltrated to some third party? Well, that’s theoretically possible, but it’s actually used for bypassing hardware authenticity checks in Cisco hardware being cloned — a sizable industry. Of course, “can’t believe it’s not Cisco” hardware is only valuable insofar that it’s able to run the Cisco software, and that’s where the bodge boards play a major role.

An unidentified IC on the a different counterfeit Cisco board, with markings soldered offA 2020 report by F-Secure details an investigation, comparing three switches marked as Cisco 2960X – one known genuine and two known counterfeits. The counterfeits had the aforementioned implants either soldered to the bottom of the PCB or added to the board as a separate component, and the paper goes into why they’re important for successful counterfeiting.

Apparently, these chips emulate or bypass an I2C EEPROM containing part of the code executed during the boot sequence, and Cisco depends on this EEPROM’s contents for authenticity verification. Cisco software reads the EEPROM twice — once for verification, and once again for actually running it. The microcontroller included on the mod board can return a genuine binary with a valid signature on the first read, and a binary with hardware checks patched out for subsequent reads.

The paper will tell you about way more than this — it’s thorough yet captivating. As you’d expect, it devotes quite a bit of time to comparing genuine and counterfeit boards, showing that the cloning process is pretty to-the-T, save for some part substitutions. For instance, check out the PDF page 12 to see how via locations are exactly copied between PCBs in a bizarre way, or the Cisco file format and authenticity check analysis closer to the end of the report. All in all, the 38 pages of the document make for a fun foray into what makes Cisco authentication mechanisms tick, and what helps clone hardware makers bypass them.

Are such chips ever used for adding backdoors and data exfiltration? There’s no evidence of that, as much as that’s not to be excluded — bypassing anti-cloning protections would make other hijinks more viable no doubt, that said, only hardware authentication bypass measures were found so far. This mechanism also breaks during software updates, and absolutely, leaves some to be desired when it comes to its stated functionality. That said, such fun insights can help us, say, enforce right-to-repair, enable hardware reuse, and thwart many predatory business practices in areas where laws fail us.

Dead Washer Lives Again With ATTiny

We aren’t saying that appliances are a scam, but we have noticed that when your appliances fail, there’s a good chance it will be some part you can no longer get from the appliance maker. Or in some cases, it’s a garden-variety part that should cost $2, but has been marked up to $40. When [Balakrishnan] had a failure of the timer control board for a Whirlpool washing machine, it was time to reverse engineer the board and replace it with a small microcontroller.

Of course, this kind of hack is one of those that won’t help you unless you need exactly that timer board. However, the process is generally applicable. Luckily, the motherboard chip was documented and the timer control board used a simple ATmega88, so it was easy to see that the devices were communicating via I2C.

Reading the I2C  bus is easy with a logic analyzer, and this revealed the faulty device’s I2C address. The board that failed was only for display, so a simple program that does nothing other than accept I2C data put the washer in working order. Once it was working with an Arduino, an ATTiny45 did the work with a lot less space and cost.

If you don’t want to reverse engineer the washing machine, you could just replace all the controls. That even works if the old washer wasn’t electronic to start.