Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
NANDcromancy: Live Swapping NAND Flash (atredis.com)
92 points by tptacek on April 27, 2021 | hide | past | favorite | 24 comments


I've got a device which I've bricked through CFE in a similar manner, I'm probably not going to unbrick it like this though :) Any tips on a cheap way to flash parallel NAND?


I've used a clip similar to the "360-clip" to reflash TSOP-48 NAND flash without desoldering. Honestly, I found it easier to desolder with chipquik than try to get a clip like the above to work though. Chipquik and a breakout board and then a SD/MMC controller (see: http://www.trapbit.com/reports/blueray-blues-1.pdf)

Edit: but, also, I'm pretty bad at this stuff and hope someone jumps in with some more experience / saner advice


This is totally reasonable advice IMO. TSOP clips are an option and work OK, but are expensive and fiddly. Rework onto a breakout board is usually the cheapest and easiest option, whether hot air or chipquik.

Another sketchy option is deadbug to the chip in situ (using solder or microclips), or test points if you're lucky and they are provided. This can be quite questionable depending on how backfeeding power into the board via the chip's Vcc works out, but is sometimes possible.


There's a lot of solutions for clipping a programmer on to an in circuit parallel Flash chip in the dozens of dollars range.


I have never found one for TSOP-48 chips beyond the 360-clip/wii-clip, do you know of others in that space for this size of chip?


There's a bunch on alibaba. A quick search also as this popping up, but I haven't tried them. https://shop.zeigren.com/


I never got a clip-on adapter working on later generation Broadcom devices. On previous ones I shorted the cs-pin to make the nand chip disappear from the SoC. Then you could flash the chip.


Were you trying to flash while the device was on?


Yes, the clip-on adapter could not power the chip in-circuit. So I use the power from the board. As I said this worked fine on some boards but not others.


I would see what's wrong with your clip. They're supposed to provide power.


Arm based devices have an early boot menu accessible by holding the "a" button. From here boot with fail-safe defaults.


Arm based devices are not consistent enough with their bootloader to allow such a thing.


Broadcom arm-based devices should have it.


The raspberry pi is a broadcom arm-based device and doesn't have it.

Perhaps if you listed a specific product segment, that might be more enlightening.


There are some interesting iPhones mods where flash can be increased well beyond what was available in a particular model (16 GiB -> 256 GiB). IIRC there's some overseas magic device that transfers stuff from the original chips to the new ones.

Also, HP 48G/GX ram chip piggybacking with proper bank selecting and extra address line decoding.

Industrial flash I had my grubby hands on circa ~2001 was rated for 10k writes per cell, but it seemed to work 1-3 orders of magnitude longer than the datasheet. In fact, it wasn't possible to get a single cell error in a reasonable time-frame despite very carefully making sure random flash test writes were occurring and reading them back.


I believe the rated write cycle also considers data retention time, over the full range of its operating temperature. If the write cycle is exceeded, it's possible that it still somewhat works at room temperature, but is unable to reach its specified data retention time, especially at high temperature.


This is a blog that is definitely worth clicking back into to read past entries. There's some really esoteric/fun stuff there like a deep dive into the Garmin smartwatch virtual machine.


On the third photo in the article, there is NAND chip pinout. And it is striking how tightly pins are packed, despite so many being "no connect". In fact, out of 48 pins on the package, only 18 are actually in use (24 if we count duplicate Vcc/Vss).

And that's not an outlier. As far as I can tell, this is a very common NAND chip pinout. I wonder - why was it done that way? Physical security feature? To make data recovery more difficult?


The specific package used is a TSOP-I-40L, standard registration JEDEC MO-142, controlling document here [0].

These things are super common for RAM or Flash in older designs or designs trying to avoid BGA parts (because BGAs are awful for anything but high-automation, high-volume work). The 0.5mm pin pitch is on the tighter side for gull-wing parts, but it's also super common itself. Many QFP processors are even tighter at 0.4mm pin pitch, and 0.5mm is very common for discretes and DFNs/QFNs. So it's no trouble whatsoever for assemblers; they do these things all day, every day, and won't even blink if you ask for one. The legs also make it amenable to manual rework, as shown in the article.

If I were designing this part in, I wouldn't think twice about using this package (used board area aside). If there were multiple packages available for a part, this one would probably actually be high on my "ease of working with" list!

[0] (Registration required) https://www.jedec.org/standards-documents/docs/mo-142-d


Great explanation, thanks.

  > I wouldn't think twice about using
  > this [TSOP-I-40/48L] package
  > ...
  > high on my "ease of working with" list
Assuming MCU/CPU can handle it, I'd personally avoid 48-pin 0.5 mm pitch TSOPs in favor of 1.27mm pitch SOIC-8/WSON-8. For 2Gbit NAND - Winbond W25N02GV, or similar part.

BTW, large-ish NOR flash (8 Mbit and up) used to be only available in 0.5-mm-pitch TSOP parallel parts only, up to a decade ago. Nowadays, it's mostly 8-pin 25Qxx parts.


Right, but you're comparing serial flash with parallel flash. Very different animals in terms of support!

I agree, there's no reason to use anything with more than 8 pins for a serial flash. Though I usually end up with MSOP or TSSOP, myself, probably since I rarely have to rework them. (Avoid the smaller DFNs, I always seem to have the worst luck with sourcing those when I need them. Even though they're always perfectly available at design-in....)

SOIC-8 is the way to go for op-amps, though. Manufacturers don't say it loudly, but any part which isn't package trimmed will always perform better in larger packages. It's not a huge effect, but if you have a free choice, why not? They're also easier to rework, and analog stuff often needs a rework or R-C across the pins or whatever.


Its a standard pinout. There are other NAND configurations like 16-bit data bus, multiple bus, multiple die that requires more pins. 16-bit data bus is pretty rare these day. Other possible reasons can be for test modes, thermal.


http://www.onfi.org/specifications - look at ONFI 4.2 page 10 for an almost-full pinout with 16-bit width and 4 independent devices ("LUNs") in one package.


Many reasons amongst which is that it’s a standard pin out of which other chips may utilise all pins. If they don’t the added bonus is the additional pins help physically secure to the board itself, as well as extra heat dissipation, etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: