Every time one of us flashes an Arduino’s internal memory, a nagging thought in the backs of our minds reminds us that, although everything in life is impermanent, nonvolatile re-writable memory is even more temporary. With a fixed number of writes until any EEPROM module fails, are we wasting writes every time we upload code with a mistake? The short answer is that most of us shouldn’t really be concerned with this unless we do what [AnotherMaker] has done and continually write data until the memory in an Arduino finally fails.
The software for this is fairly simple. He simply writes the first 256 ints with all zeros, reads them to make sure they are all there, and then repeats the process with ones. After iterating this for literally millions of times continuously over the course of about a month he was finally able to get his first read failure. Further writes past this point only accelerated the demise of the memory module. With this method he was able to get nearly three million writes before the device failed, which is far beyond the tens or hundreds of thousands typically estimated for a device of this type.
To prove this wasn’t an outlier, [AnotherMaker] repeated the test, and did a few others while writing to a much smaller amount of memory. With this he was able to push the number of cycles to over five million. Assuming the Arduino Nano clone isn’t using an amazingly high-quality EEPROM we can safely assume that most of us have nothing to worry about and our Arduinos will be functional for decades to come. Unless a bad Windows driver accidentally bricks your device.
Last month Kia Motors announced a large recall due to possibly defective airbag controller units (ACU). The recall spans many models and model years — in the United States alone it covers over 400K cars, and over half a million cars worldwide. From the NHTSA report we learn that the problem happened at assembly when the cover of some ACUs interfered with the pins of an EEPROM chip. This can cause some of the pins to open-circuit. If your car had this problem, a warning light would come on, but more seriously, the airbags would not deploy in an accident. Kia estimates that less than 1% of the cars using this ACU have this issue. Cars which have this fault will get a new ACU, and other cars will get a firmware upgrade to keep this from happening should the EEPROM pins break loose in the future.
We think this EEPROM is used for logging errors and crash events, and is therefore not in the critical path for airbag deployment. The original firmware apparently prevented deployment if the EEPROM had a fault. Presumably, after this patch, if pins break in the future, the fault indicator still lights up but you’ll have functioning airbags.
It’s not clear if these broken EEPROM pin solder joints were present from the start and the factory test procedures didn’t catch the problem. Or did the pins left the factory intact and were subsequently broke due to bumps and vibrations. Hardware issues aside, having safety critical firmware perform its primary function even when faults exist in non-essential parts of the circuit seems like a requirement that should have been applied to the ACU from the beginning.
This is a reminder of the importance of enclosure design and making sure your PCB layouts take into account all clearances necessary for the entire assembly. How many times have you got your PCB back and realized you forgot to even put mounting holes?
With the Pi Pico standing in for the original ROM, updating firmware takes a fraction of the time and doesn’t require you to actually disconnect any of the hardware. [Nick] had done something similar with FPGAs in the past, but the far cheaper and easier to work with Pi Pico makes this version particularly appealing. The secret to getting it to work is the overclocking potential of the Pico, which he says has been pushed to 400 MHz for this particular application.
The downside is that you can’t access the Pico’s onboard flash when the chip is running that fast. To get around that limitation, all of the code is loaded into the microcontroller’s RAM. With a healthy 264 KB of memory this isn’t really a problem when emulating 32 KB chips, but [Nick] says his method would quickly fall apart for larger ROMs.
Beyond the Pi Pico itself, [Nick] is using a trio of 74LVC245AN 8-bit logic level shifters so the chip can talk to the 5 V logic of his homebrew 6502 computer. With everything wired up on a simple breadboard, PicoROM has no trouble serving up the operating system as it hums along at 2 MHz.
Has it really come to this? Are we really at the point that dishwashers have proprietary detergent cartridges that you’re locked into buying at inflated prices?
Apparently so, at least for some species of the common kitchen appliance. The particular unit in question goes by the friendly name of Bob, and is a compact, countertop unit that’s aimed at the very small kitchen market. [dekuNukem] picked one of these units up recently, and was appalled to learn that new detergent cartridges would cost an arm and a leg. So naturally, he hacked the detergent cartridges. A small PCB with an edge connector and a 256-byte EEPROM sprouts from each Bob cartridge; a little reverse engineering revealed the right bits to twiddle to reset the cartridge to its full 30-wash count, leading to a dongle to attach to the cartridge when it’s time for a reset and a refill.
With the electronics figured out, [dekuNukem] worked on the detergent refill. This seems like it was the more difficult part, aided though it was by some fairly detailed specs on the cartridge contents. A little math revealed the right concentrations to shoot for, and the ingredients in the OEM cartridges were easily — and cheaply — sourced from commercial dishwashing detergents. The cartridges can be refilled with a properly diluted solution using a syringe; the result is that each wash costs 1/75-th of what it would if he stuck with OEM cartridges.
For as much as we despise the “give away the printer, charge for the ink” model, Bob’s scheme somehow seems even worse. We’ve seen this technique used to lock people into everything from refrigerator water filters to cat litter, so we really like the way [dekuNukem] figured everything out here, and that he saw fit to share his solution.
If you really think hard about it, a CPU is just a very general-purpose state machine. Well, most CPUs are, anyway. The MC14500 is a one-bit computer that has only 16 instructions and was meant to serve in simple tasks where a big CPU wouldn’t work for space, power, or budget reasons. However, [Laughton] took the idea one step further and created a single-bit computer with no real instructions to control a printing press. The finished machine uses a clever format in an EEPROM to drive an endless program.
Honestly, we’d say this is more of a state machine, but we like the idea of it being a minimal CPU which is also true. The design uses the EEPROM in an odd way. Each CPU address really addresses a block of four bytes. The byte that gets processed depends on the current phase and the status of the one-bit flag register.
When learning a new programming language, it’s best to have a goal in mind and work towards it. [Timo] thought it was about time to learn python, and he also had a project in mind: removing the BIOS supervisor password from his old Thinkpad. From there it was just a few keystrokes (and some soldering) and he was able to change the BIOS password of this black box from the outside.
The build utilizes a BeagleBone to communicate with the laptop’s EEPROM via the I2C bus. An oscilloscope also monitors the bus to look for a specific window every four-seconds when the computer is not accessing the bus. During that short period, the EEPROM can be read and written to. Once the window opens, the BeagleBone executes the Python script, which attempts to read the EEPROM and can also perform actions such as removing or changing the BIOS supervisor password.
Of course, tinkering with the EEPROM on a laptop has a high risk of bricking the device, and not all laptops use the same security measures or even memory addresses for things like this, so documentation and precision are key. Also, with Thinkpads of this vintage it’s possible to replace the firmware on these chips entirely with a FOSS version called libreboot, and even though the process is difficult, it’s definitely recommended.
Game cartridges are perhaps the hardiest of all common storage schemes. Short of blunt traumatic force or application of electrical surges to the cartridge’s edge connectors, damaging a game cartridge is hard to do by accident. The same is also true for the data on them, whether one talks about an Atari 2006 cartridge from the late 1970s or a 1990s Nintendo 64 cartridge.
The secret sauce here are mask ROMs (MROM), which are read-only memory chips that literally have the software turned into a hardware memory device. A mask layer unique to each data set is used when metalizing the interconnects during chip fabrication. This means that the data stored on them is as durable as the processor in the game console itself. Yet this is not a technology that we can use in our own hobby projects, and it’s not available for personal long-term data storage due to the costs associated with manufacturing what is essentially a custom chip.
Despite its value as truly persistent storage, MROM has fallen out of favor over the decades. You may be surprised to find a lot of what’s currently used in the consumer market is prone to data corruption over time spans as short as one year to one decade depending on environmental conditions.
So what are we to do if we need to have read-only data that should remain readable for the coming decades?