When [sticilface] started using the Arduino IDE to program an ESP8266, he found he was running out of RAM quickly. The culprit? Strings. That’s not surprising. Strings can be long and many strings like prompts and the like don’t ever change. There is a way to tell the compiler you’d like to store data that won’t change in program storage instead of RAM. They still eat up memory, of course, but you have a lot more program storage than you do RAM on a typical device. He posted his results on a Gist.
On the face of it, it is simple enough to define a memory allocation with the PROGMEM keyword. There’s also macros that make things easier and a host of functions for dealing with strings in program space (basically, the standard C library calls with a _P suffix).
Continue reading “Save ESP8266 RAM with PROGMEM”
If you’ve ever corrupted a flash memory on a power failure, you’ll be glad to hear that the ESP8266 SDK implements a very secure and almost infallible read/write management for its flash memory. The catch: It’s also very wasteful. For a single memory block of stored data, three memory blocks of physical flash memory are occupied. [Peter Scargill] enlightens us with a better solution.
Continue reading “Overhauling The ESP8266’s Flash Memory Handling”
An SD card is surely not an enterprise grade storage solution, but single board computers also aren’t just toys anymore. You find them in applications far beyond the educational purpose they have emerged from, and the line between non-critical and critical applications keeps getting blurred.
Laundry notification hacks and arcade machines fail without causing harm. But how about electronic access control, or an automatic pet feeder? Would you rely on the data integrity of a plain micro SD card stuffed into a single board computer to keep your pet fed when you’re on vacation and you back in afterward? After all, SD card corruption is a well-discussed topic in the Raspberry Pi community. What can we do to keep our favorite single board computers from failing at random, and is there a better solution to the problem of storage than a stack of SD cards?
Continue reading “Single Board Revolution: Preventing Flash Memory Corruption”
We just got through reviewing MicroPython on the ESP8266, and one of the main takehomes is that our ESP modules need more flash memory. You may be in the same boat — the earliest (and cheapest) modules on the market only had 512 kB of flash. For over-the-air programming, or to give you some more space for fancier programs, you’re going to want 1 MB or even 4 MB.
The solution? Just buy a new flash chip and solder it on. This is especially easy if you’ve got an ESP-01, ESP-03, or ESP-11 modules where the flash chip is exposed. Desolder, resolder, done. It can be a little trickier for those modules with a tin can around chips, but that’s nothing that a little hot air can’t fix. See the video embedded below for a good walk-through.
Continue reading “Your ESP8266 Needs More Memory”
In this post on the Arduino.cc forums and this blog post, [Majek] announced that he had fooled the AVR microcontroller inside and Arduino into writing user data into its own flash memory during runtime. Wow!
[Majek] has pulled off a very neat hack here. Normally, an AVR microcontroller can’t write to its own flash memory except when it’s in bootloader mode, and you’re stuck using EEPROM when you want to save non-volatile data. But EEPROM is scarce, relative to flash.
Now, under normal circumstances, writing into the flash program memory can get you into trouble. Indeed, the AVR has protections to prevent code that’s not hosted in the bootloader memory block from writing to flash. But of course, the bootloader has to be able to program the chip, so there’s got to be a way in.
The trick is that [Majek] has carefully modified the Arduino’s Optiboot bootloader so that it exposes a flash-write (SPM) command at a known location, so that he can then use this function from outside the bootloader. The AVR doesn’t prevent the SPM from proceeding, because it’s being called from within the bootloader memory, and all is well.
The modified version of the Optiboot bootloader is available on [Majek]’s Github. If you want to see how he did it, here are the diffs. A particularly nice touch is that this is all wrapped up in easy-to-write code with a working demo. So next time you’ve filled up the EEPROM, you can reach for this hack and log your data into flash program memory.
Thanks [Koepel] for the tip!
[Gene] has a project that writes a lot of settings to a PIC microcontroller’s Flash memory. Flash has limited read/erase cycles, and although the obvious problem can be mitigated with error correction codes, it’s a good idea to figure out how Flash fails before picking a certain ECC. This now became a problem of banging on PICs until they puked, and mapping out the failure pattern of the Flash memory in these chips.
The chip on the chopping block for this experiment was a PIC32MX150, with 128K of NOR Flash and 3K of extra Flash for a bootloader. There’s hardware support for erasing all the Flash, erasing one page, programming one row, and programming one word. Because [Gene] expected one bit to work after it had failed and vice versa, the testing protocol used RAM buffers to compare the last state and new state for each bit tested in the Flash. 2K of RAM was tested at a time, with a total of 16K of Flash testable. The code basically cycles through a loop that erases all the pages (should set all bits to ‘1’), read the pages to check if all bits were ‘1’, writes ‘0’ to all pages, and reads pages to check if all bits were ‘0’. The output of the test was a 4.6 GB text file that looked something like this:
Continue reading “Flash Memory Endurance Testing”
NAND flash, the same memory chips found in everything from USB thumb drives to very expensive solid state disk drives, are increasingly common. As they (partially) serve as the storage for cellphones, Wiis, routers and just about every piece of consumer electronic devices, you’re probably surrounded by dozens of NAND chips at any one time.
[Sprite_tm], hacker extraordinaire, put up a build a few years ago where he was able to read the contents of NAND Flash chips using a PC parallel port. It’s getting rather hard to find a parallel port on a PC anymore, so he updated his build to read Flash chips off of a USB port.
There are two main components of [Sprite_tm]’s build. First, to read the Flash chip, he needed a way to break out the pins on the very tiny TSOP48 package. [Sprite] found a neat little socket for these chips on eBay for about 10 Euros.
Communicating with the Flash chip via USB was a little harder. [Sprite] knew he needed USB 2.0, but not many microcontrollers have that implemented. Luckily, the FTDI FT2232H has USB 2.0, along with the very nice feature of being able to read data and address pins directly from the Flash chip. After a bit of soldering, [Sprite_tm] was left with the device seen above.
[Sprite_tm] found a nice library to bitbang the pins on the FTDI chip and request one page of memory from the Flash chip at a time. The device works as advertised, but it’s still a bit slow at 250 kBps. [Sprite] figures he can increase the speed of reading a Flash chip by requesting multiple pages at a time, but it’s still orders of magnitude faster than the old parallel port solution.
There’s a good bit of software [Sprite] posted to help him (and possibly others) read bare NAND flash chips via USB. This means if you have a broken USB Flash drive or SD card, it’s possible to desolder the chip and read it with your own controller. Interpreting the blocks of data recovered from a Flash drive as a file system is another story, but it’s still a fairly remarkable build.