Switching Converter For EEPROM Programmer Taxes Solderless Breadboard

We all know that solderless breadboards have their limitations. All that stray capacitance can play hell with circuits, especially high-speed stuff, but they’re so darn useful that avoiding them in favor of some other prototyping method can be really hard. So we often just forge ahead, plugging in our parts and hoping for the best

A recent veteran of the breadboard battle is [Anders Nielsen], who kicked off a new project by prototyping this high-voltage boost converter on a breadboard, with mixed results. The project is a scratch-built programmer for old-school ROM chips, a task normally farmed out to a dedicated programmer, but where’s the sport in that? Besides, this is the future, and generating the 12 to 14 volts needed should be a snap. And it would be, except for the fact that his chosen chip, a MIC2288 switching boost regulator, is only available in an SMD package. Getting the chip and a few other SMD support components onto breadboard-compatible breakouts proved to be challenging, and getting it working once it was there was even more work.

A lot of the trouble was down to simple breadboarding errors, but the big problem was the input capacitance, which [Anders] had to fiddle with quite a bit to get the converter to 14 volts. The current maxes out at about 25 mA before the voltage starts dropping, which just might be enough to burn those old chips, so we’ll call this a provisional win and see what happens when he builds the rest of the programmer.

[Anders]’ experience here raises a good question: what’s the best way to prototype using fussy SMD components? PCBs are cheap enough that it’s tempting to go straight to one, but swapping parts in and out like he had to do here to get everything just right would be much harder that way. We’re not sure we know the answer, but we’re pretty sure we’ll hear your thoughts on that in the comments section.

Continue reading “Switching Converter For EEPROM Programmer Taxes Solderless Breadboard”

Die of an Altera EPM7032 EEPROM-based Complex Programmable Logic Device (CPLD). (Credit: ZeptoBars, Wikipedia)

Using EPROMS And EEPROMs As Programmable Logic With Lisp

That EPROMs, EEPROMs and kin can be used as programmable logic should probably not come as a major surprise, but [Jimmy] has created a Lisp-based project that makes using these chips as a logic array very straightforward. All it takes is importing the package into one’s Lisp project and defining the logic, before the truth function generates the binary file that can be written to the target chip.

Suggested is the one-time-programmable AT27C512R EPROM (64k x8), but any 8-bit parallel interface (E)EPROM should work, with non-OTP chips being nice unless the chip has to go into a production device. A possible future improvement is the addition of 16-bit (E)EPROM support.

The use of EEPROMs is common with PLA-replacements, as with, for example, the Commodore 64, where the official PLA IC tends to go bad over time. Due to the complexity of the logic in these PLA ICs, here CPLDs are used, which internally are still EEPROM-based, but feature many more programmable elements to allow for more complex logic. If all you need is a bit of glue logic and you are looking for something in between a stack of 74-logic ICs and a CPLD, an EEPROM may be just be the solution, regardless of whether you prefer to create the binary image with Lisp or C.

Continue reading “Using EPROMS And EEPROMs As Programmable Logic With Lisp”

Stuffing A 32-Pin Chip Into A 28-Pin Socket

What’s the difference between a 64k ROM in a 28-pin DIP and a 128k ROM in a 32-pin DIP? Aside from the obvious answers of “64k” and “four pins,” it turns out that these two chips have a lot in common, enough so that it only takes a little bodging to make them interchangeable — more or less.

For a variety of reasons revealed in the video below, [Anders Nielsen] use the SST39SF010, a Flash ROM in a 32-pin DIP, in place of the old standby W27C512, an EEPROM in a 28-pin DIP. To deal with those pesky extra pins on the Flash ROM, [Anders] dug into the data sheets and found that thanks to JEDEC standards, almost everything about the pinouts of the two chips is identical. The only real difference is the location of Vcc, plus the presence of a 16th address bus line on the more capacious Flash ROM.

Willing to sacrifice the upper half of the Flash chip’s capacity, [Anders] set about bodging the 32-pin chip to work in a 28-pin socket. The mods include a jumper from pin 32 to pin 30 on the Flash chip, which puts Vcc in the right place, and adding a couple of pull-up resistors for write-enable and A16. Easy enough changes, but unfortunately, [Anders] chose a Flash ROM with heavily oxidized pins, leading to some cold solder joints and intermittent problems while testing. There’s also the fact that not all boards have room for overhanging pins, a problem solved by adding a socket to create a little vertical clearance.

We found this to be a neat little hack, one that should make it a bit easier to use the wrong chip for the job. If you want to see where [Anders] is using these chips, check out his 6502 in an Arduino footprint or the bring-up of an old XT motherboard.

Continue reading “Stuffing A 32-Pin Chip Into A 28-Pin Socket”

Stress-Testing An Arduino’s EEPROM

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.

Continue reading “Stress-Testing An Arduino’s EEPROM”

Kia Recalls Cars Over Airbag Controller Assembly Issue

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?

We covered a similar issue a couple of years ago regarding the Takata airbag fiasco. If you have a Kia, this form on their website tells you whether your vehicle is subject to the recall or not.

Pi Pico Emulates ROM For Speedy Retro Hacking

If you’ve ever worked on a system that loads its software from a ROM or EPROM, you know how much of a hassle it can be to make frequent changes to the code. Pulling the chip, flashing it, and sticking it back into the socket each time you change a line isn’t anyone’s idea of a good time. Which is why [Nick Bild] has come up with the PicoROM, a way to emulate a ROM chip using the Raspberry Pi Pico.

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.

PicoROM on a breadboard.

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.

Of course, a modern high-performance microcontroller isn’t strictly necessary. In the past we’ve covered devices that could emulate an EPROM using 1990s era silicon.

Detergent DRM Defeated On Diminutive Dishwasher

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.