Mmm.. Okay, Status 0xa2 is composed of these three bits:

0x80 :: Device is idle.
0x20 :: Erase failed.
0x02 :: Prog/Erase attempted on a locked block, operation aborted.

So, probably not bad flash, but something wrong with the programming method. The download.c source code appears to correctly attempt to unlock blocks before erasing them, so this shouldn't be happening. I'll look a little closer to see if Hugo has a bug in there somewhere..

EDIT: Ah. The download.c program is actually sending commands to a firmware blob on the empeg, which is then talking to the flash memory. So if there's a bug, it appears to be in that firmware blob. Ugh.


Or maybe something has gone wrong with the WP input to the flash chip? I think that's only to protect the mysterious firmware blob itself, not the rest of the flash.