Perhaps the most annoying kinds of faults are those that involve expensive equipment that just sit around in a cupboard, only for them to just stop working at all. Such was the case with the £2,000 Amprobe cable trace kit that [Tom] bought for work-related purposes. After sitting around unused for a few years, the signal generating part of the kit refused to power up at all, with Fluke’s service department wanting at least £600 to even attempt a repair after already having had [Tom] cough up £70 to even get this quote.

Subsequently he instead sent it to [Buy it Fix it] on YouTube for an attempted repair, which at the very least would be a less costly option. These systems use a signal generator connected to the cable, with a separate detector wirelessly tracking this signal. By itself that doesn’t sound too complex, but as it turns out it wasn’t quite so straightforward to diagnose.

After eliminating a basic power or display issue, the SoC’s boot sequence was traced, including reading from the 128 MB NAND Flash. At first glance the unit appeared to be trying to boot and work as normal, which was confirmed after finding a serial port and seeing the log output on it. This showed that the NAND Flash’s boot image failed validation due to apparent corruption.

After desoldering the TSOP 48 Flash package and stuffing it into a reader, at first glance the data on it looked fine. After a tragic detour with Google’s Gemini chatbot that led to a lot of wasted time, the solution that the human intelligence came up with was to crack open the tracer unit in the set and ogle at its firmware, in particular the bootloader.

Comparing the two Flash dump files, there were a few flipped bits in the bootloader section, likely due to cells in the Flash having lost their charge. Writing the generator’s Flash with a corrected image led to it booting up happily again into the Linux 2.6-based firmware, seemingly no worse for wear. Of course, one has to consider here that the NAND Flash IC clearly has a few leaky cells in it, so replacing it with a fresh one could be a good idea for a long-term fix.

If you are a regular reader, then the odds are you have taken apart an electronic gadget, either for a fix, or simply because your curiosity got the better of you. Once inside, it’s all but impossible to help yourself from doing at least a little reverse engineering. That’s what happened when [PRBS23] took a look inside a MasterBuilt Gravity 800 Grill for a simple wire fix. But one thing led to the next, and now open source firmware for the grill is freely available!

The first order of business in creating the firmware is reverse engineering the original controller. Opening it up immediately reveals an ESP-32 and a well-labeled programming port. The rest of the control board is equally simple, including connectors for four thermistor temperature sensors, lid open/close switch, fan driver, 16 segment LCD, piezo buzzer, and some physical inputs.

The thermistor along with the physical inputs are connected to a 16 pin chip, interfacing with the MCU over a 9600 baud UART connection. [PRBS23] cannot determine an ADC chip meeting these specifications, so the most likely answer is a cheap MCU programmed to act as a simple analog fronted.

The neatly labeled programming header is used to quite easily dump the firmware with the espflash utility. Analyzing this dump reveals a rather strange ADC correction function used by the original firmware. The necessity and overall utility of this function remains unclear, does corrects a maximum of around 40 degrees Fahrenheit.

Most of the other features ended up being at least somewhat easier. The CS1621 segmented display driver is reasonably well documented with datasheets making its implementation far easier. Likewise, the other odds and ends were implemented in a far more normal manner compared to the thermistors.

All this reverse engineering work got tied together into a neat little firmware package. It comes with over the air updates PID controlled temperature, and a real-time web interface. This also isn’t the first time we have seen an IoT device liberated from proprietary firmware, and this remains one of our favorite uses of reverse engineering!