Bodging On More Flash Memory

[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.

32 thoughts on “Bodging On More Flash Memory

    1. Bill Gates actually wasn’t the guy who said that. It was an IBM engineer (whose name is lost to history) on the architecture of the IBM PC. The 640kb barrier was never a limitation of DOS, it was a limitation of the PC.

    2. I attended a seminar many years ago where the guy giving the talk said he was present when Bill Gates said that… I had a feeling he was a liar. haha… Has Bill Gates ever responded to that publicly? No, I didn’t search for it, but I think I will right now. [done searching for the answer I wanted]

      There is this:
      “I’ve heard someone saying that this sentence was actually said by an IBM engineer. Unfortunately I don’t remember where I read it and neither the engineer’s name. Do you know something about this?”

      “640K ought to be enough for anybody” *was* *definitely* said by Bill Gates. He said it at an early microcomputer trade show in Seattle in mid 1981. It is the Microsoft PR machine that has tried over the years to rewrite history and pretend that Gates never made this asinine comment.”

      From here: https://en.wikiquote.org/wiki/Talk:Bill_Gates#640_k.2F1_MB

      No way to prove or disprove it for now it seems. Would love to hear if someone else might have attended that trade show in 1981 where he allegedly said that.

      1. Even if Gates said it (and as you pointed out there is no proof he did) it was never Microsoft’s fault. To the contrary Microsoft went to great lengths to get past the 640kB limit (such as standardizing bank switching mechanisms).

    1. Flash memory is erased by setting all the bits in a sector to ‘1’, and writing works by setting a particular bit to ‘0’. For instance I am working on software for an application with a 32 mb flash chip, that can only be erased in 4kb chunks. My MCU has enough RAM to buffer an entire 4kb chunk, so ‘editing’ a 4kb chunk is straightforward – read the contents into RAM, erase the chunk, rewrite modified contents.

      If I was using that same chip with say, an Atmega328, I would have to copy the whole 4kb chunk somewhere else on the flash chip – then erase the old chunk and rewrite it using the new saved copy for reference. This is slower, wears the chip out faster and uses more energy. If you did have to develop a robust device using a flash chip whose minimum eraseable chunk is too big to be stored in RAM, you would also need to come up with a scheme to rotate which parts of the chip are used as the temporary storage to level the wear out.

    2. If your code fits in 32kB and runs on a $0.50 device, why would you pay $3+ each for devices with 2MB? Especially when you’re building 100,000 of them.

      Secondly, “cheap, tiny” flash memory is unreliable flash memory that works only because there is a block-remapping layer above it. Code space for a micro needs to be utterly reliable have no holes (much higher yield) – it is therefore coarser and orders of magnitude more expensive. Also, there’s no way that a manufacturer is going to put two dies (from different processes) in a $0.50 device because the assembly costs are too high.

    3. Yeah, remember that the processes used to make very high density flash memory are very different from those that are used to make MCUs. You can’t actually put both on the same piece of silicon without making a ton of tradeoffs. For one, the transistors on flash memory processes are usually a lot less reliable. Usually these errors are corrected for using a separate flash memory controller logic on a separate chip that manages all the different memory banks and bypasses any bad ones.

      Additionally to keep costs low, consumer flash memory can only handle things in fairly large blocks. Often times this block is larger than what lower end MCUs could reasonably handle.

      Thus, flash memory area is probably easily 10-100x larger on a embedded range MCU (ATmega, Cortex-M0/M3/M4, etc.) than on a dedicated flash die.

      When there’s really a need for more flash memory, it’s becoming more common on higher end devices to just stack a high density flash die and an MCU die. Of course, this process isn’t cheap, so it only happens when that much flash memory is genuinely necessary.

  1. Scott (aka tannewt) here. I’m the lead dev on CircuitPython. Much of the flash is taken up by the MicroPython core which reimplements python 3.4. Another good chunk of the flash is used by C backed modules that provide APIs to the hardware itself. Lastly, boards without external SPI flash have internal file systems on the SPI flash that are used to store user code. The Gemma M0 and Trinket M0 have 64kb file systems on them. Adding external SPI flash frees up that 64k for more C modules and gives way more space for user code.

    The end result is, in essence, a self-contained toolchain. The input to CircuitPython is human readable text via USB mass storage and the rest is done in the microcontroller. A bonus perk is that your code goes with you in a human editable manner. So, you can plug it into a different computer to edit it and never worry about where you saved it or if you emailed it to yourself first.

  2. I got my hands on one of these. They are VERY will put together. Really is plug and play. If you can, get one. If your an old school asm / c / c++ coder like me, you may find your view of what is needed to create embedded devices change. Throw that IDE away. :) It’s back to that instant on and coding of the 80’s and the 8bit systems like the ZX80 / ZX81 I started coding on in BASIC.

    1. This is definitely a hack, by all definitions: it’s a workaround, it’s kinda sketchy, and it is a creative abuse of tech.

      Now if it were me, I would have redesigned the board. Break out some of those extra pins, etc. But then it wouldn’t have this ultra-tiny form factor. And that would be engineering, and not a hack.

    1. It’s super irritating that, in a world where storage and battery life are both very valuable considerations for consumers, manufacturers keep removing expanded storage slots and squishing devices to ever thinner form factors and thus reducing battery sizes. I don’t know anyone that would choose the “paperphone 47” over the “battery lasts a week and it holds every photo you ever tookphone” at twice the thickness.

  3. Original DOS was written for the original IBM PC using 8088 CPU which had 20 address lines and therefore could only use 1MB of memory. So, yes, it was a limitation to DOS. Remember that it was all a mess because x86 architecture used 64kB segments—which actually made it easier to adapt DOS for CPUs with more than 20 bit address bus: it was just more segments.

    1. “Original DOS was written for the original IBM PC using 8088 CPU which had 20 address lines and therefore could only use 1MB of memory. So, yes, it was a limitation to DOS.”

      No it wasn’t. Everything above 640kB was reserved by the BIOS or graphics memory. Also the first kB of memory was reserved for the interrupt table.

      http://wiki.osdev.org/Memory_Map_(x86)

      Note that the BDA and EBDA didn’t exist on the first PC.

  4. Elliot, it was 100% “wouldn’t it be neat”. That, to me, is the very essence of a hack. It was also an exercise in diving into the SAMD21 hardware and the CircuitPython codebase.

    I since built another that’s a fair bit neater. A photo of that has been added to the original post.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.