[Pete] was building a hot tub controller, using a WEMOS board based on the venerable ESP8266. After assembly, the board was plugged into USB and [Pete] hit the flash button. No dice. Investigation with some terminal software indicated a checksum error.
Assuming the board was dead, [Pete] grabbed another — and suffered the same problem. The WEMOS boards wouldn’t program, but other boards had no issues. Sensing that something may be amiss, further research was in order. A forum post turned up discussing different programming modes for the ESP8266.
It turns out that there are different types of flash used with the ESP8266, and the correct programming mode must be selected for a given hardware setup. These modes are known as DIO and QIO, meaning “dual IO” and “quad IO” respectively. This refers to the number of IO line used to talk to the flash memory. There are also further modes, known as DOUT and QOUT. It’s important to identify the modes supported by the flash chip on board, by looking at the datasheet. Obviously this can be difficult on some pre-built modules, so experimentation is the key here.
With the wrong mode selected, writes to the flash will fail, and reading back will turn up a checksum error. It’s a simple matter of changing a line in the make file and trying different modes, to see which one works. This forum post has a more in-depth coverage of the issue.
By choosing different flash memory parts and selecting the DIO or DOUT modes, it’s actually possible to free up more GPIO pins as well. This knowledge is handy when optimizing ESP8266 designs for memory speed or maximum IO flexibility. It’s a good lesson that it always pays to look at the datasheet to get the best out of your parts.
[Curmudegeoclast] found himself running out of flash memory on a Trinket M0 board, so he decided to epoxy and fly-wire a whopping 2 MB of extra flash on top of the original CPU.
We’ll just get our “kids these days” rant out of the way up front: the stock SAMD21 ARM chip has 256 kB (!) of flash to begin with, and is on a breakout board with only five GPIO pins, for a 51 kB / pin ratio! And now he’s adding 2 MB more? That’s madness. The stated reason for [Curmudegeoclast]’s exercise is MicroPython, which takes up a big chunk of flash just for the base language. We suspect that there’s also a fair amount of “wouldn’t it be neat?” in the mix as well. Whatever.
The hack is a classic. It starts off with sketchy wires soldered to pins and breadboarded up with a SOIC expander board. Following that proof of concept, some degree of structural integrity is brought to the proceedings by gluing the flash chip, dead-bug, on top of the microcontroller. We love the (0805?) SPI pullup resistor that was also point-to-point soldered into place. We would not be able to resist the temptation to entomb the whole thing in hot glue for “long-term” stability, but there are better options out there, too.
This hack takes a minimalist board, and super-sizes it, and for that, kudos. What would you stuff into 2 MB of free flash on a tiny little microcontroller? Any of you out there using MicroPython or CircuitPython care to comment on the flash memory demands? 256 kB should be enough for anyone.
How do I get the data off this destroyed phone? It’s a question many of us have had to ponder – either ourselves or for friends or family. The easy answer is either spend a mint for a recovery service or consider it lost forever. [Trochilidae] didn’t accept either of those options, so he broke out the soldering iron and rescued his own data.
A moment’s inattention with a child near a paddling pool left [Trochilidae’s] coworker’s wife with a waterlogged, dead phone. She immediately took apart the phone and attempted to dry it out, but it was too late. The phone was a goner. It also had four months of photos and other priceless data on it. [Trochilidae] was brought in to try to recover the data.
The phone was dead, but chances are the data stored within it was fine. Most devices built in the last few years use eMMC flash devices as their secondary storage. eMMC stands for Embedded Multimedia Card. What it means is that the device not only holds the flash memory array, it also contains a flash controller which handles wear leveling, flash writing, and host interface. The controller can be configured to respond exactly like a standard SD card.
The hard part is getting a tiny 153 ball BGA package to fit into an SD card slot. [Trochilidae] accomplished that by cutting open a microSD to SD adapter. He then carefully soldered the balls from the eMMC to the pins of the adapter. Thin gauge wire, a fine tip iron, and a microscope are essentials here. Once the physical connections were made, [Trochilidae] plugged the card into his Linux machine. The card was recognized, and he managed to pull all the data off with a single dd command.
[Trochilidae] doesn’t say what happened after the data was copied, but we’re guessing he analyzed the dump to determine the filesystem, then mounted it as a drive. The end result was a ton of recovered photos and a very happy coworker.
If you like crazy soldering exploits, check out this PSP reverse engineering hack, where every pin of a BGA was soldered to magnet wire.
Photography is all about light. It’s literally right there in the name – stemming from the Greek word, photos. This is why photographers obsess over the time of day of a shoot, why Instagrammers coalesce around landmarks at sunset, and why a flash helps you take photos in darkness. Historically, flashes have worked in all manner of ways – using burning magnesium or xenon lamps for example. For this Hackaday Prize entry, [Yann Guidon] is developing a portable flash using LEDs instead.
By this point in time, you might be familiar with LEDs as flash units from your cellphone. However, [Yann] is taking this up a notch. The build is based around 100W LED modules, which obviously can pump out a lot of light. The interesting part of the build is its dual nature. The LEDs are intended to operate in one of two ways. The first is in a continuous lighting mode, running the modules well below their rated power to reduce the stress on the LEDs and power supply, and to enable the flash to run on the order of an hour. In this mode, temperature feedback will be used to control the LEDs to manage power use. The other is a pulsed mode, where the LED will be overvolted for a period of milliseconds to create a much more powerful flash.
It’s this dual nature which gives the LED-based flash a potential advantage over less versatile xenon-based units, which are limited to pulsed operation only. We can see the continuous lighting mode being particularly useful for videographers needing a compact, cheap lighting solution that can also work as a pulsed unit as well.We’re excited to see how [Yann] tackles the packaging, thermal and control issues as this project develops!
Like a lot of mass-produced consumer goods, it turns out that the internal workings of Bluetooth headphones are the same across a lot of different brands. One common Bluetooth module is the CSR8645, which [lorf] realized was fairly common and (more importantly) fairly easy to modify. [lorf] was able to put together a toolkit to reprogram this Bluetooth module in almost all of these headphones.
This tip comes to us from [Tigox] who has already made good use of [lorf]’s software. Using the toolkit, he was able to reprogram his own Bluetooth headphones over a USB link to his computer. After downloading and running [lorf]’s program, he was able to modify the name of the device and, more importantly, was able to adjust the behavior of the microphone’s gain which allowed him to have a much more pleasant user experience.
Additionally, the new toolkit makes it possible to flash custom ROMs to CSR Bluetooth modules. This opens up all kinds of possibilities, including the potential to use a set of inexpensive headphones for purposes other than listening to music. The button presses and microphones can be re-purposed for virtually any task imaginable. Of course, you may be able to find cheaper Bluetooth devices to repurpose, but if you just need to adjust your headphones’ settings then this hack will be more useful.
[Featured and Thumbnail Image Source by JLab Audio LLC – jlabaudio.com, CC BY-SA 4.0]
The Raspberry Pi Camera is a great tool; it allows projects that require a camera to be put together quickly and on a budget. Plus, having a Linux back end for a little processing never hurt anybody. What can be difficult however, is imaging in low light conditions. Most smartphones have an LED flash built in for this purpose. [Wim Van Gool] decided to follow suit and build an LED flash for the Raspberry Pi.
The project consists of a custom PCB with surface-mount LEDs in an attractive concentric layout. This is a good way to get a nice even distribution of light, particularly when taking photos close up. The board is designed around the Texas Instruments TPS61169 LED driver, which is controlled by a PWM signal from the Raspberry Pi. The flash mounts as a Raspberry Pi HAT, and there’s a hole routed in the centre to allow the camera to fit in nice and snug when using standard 11mm standoffs. It might seem simple, but it’s an impressively tidy piece of engineering and a testament to [Wim]’s abilities.
The Raspberry Pi Camera turns up in all sorts of projects — like these far-seeing PiNoculars.
[Huan Truong] was given a WiFi router and thought he’d improve it by installing a free firmware on it. Unfortunately, the router in question is a bit old, and wasn’t ever popular to begin with, which meant that it was unsupported by the usual open firmware suspects. The problem was that it only had a 4 MB flash to boot off of, but [Huan] was determined to make it work. (Spoiler: he did it, and documented it fully.)
The flash workaround consisted basically of repartitioning the space, and then telling u-boot where to find everything. On a router like the WNR2000 that [Huan] had, the flash is memory-mapped, which meant adding an offset to the flash start (
0xbf000000 instead of
0x00000000) and remembering to do this consistently so that he doesn’t overwrite things like the MAC address.
[Huan] went for the LEDE fork of OpenWRT, and rebuilt it from source because he needed a small version to fit inside his limited flash. With this task completed, it worked. All done? Nope, [Huan] then submitted a pull request to LEDE, and now you can enjoy the fruits of his labor without replicating it. But if you’ve got another low-flash, obscure router, you’ve got a head start in getting LEDE up and running on it.
Routers are perhaps the most-hacked device that we see here, and they can be made pretty darn useful with the right firmware. Sometimes getting a custom firmware running is relatively easy, as it was here, and sometimes it requires some deep reverse engineering. But it’s good to keep up your router-hacking chops, because they may not always be as open as they are now.