Oh maybe load a program through jtag of the mcu and have it do the work. Bit bang with boundary scan, design your board with a header to hold mcu in reset or isolate spi bus if you have to and program it directly with something like this USB to spi decice (comes with c API for host).
You could order the flash parts preprogrammed from any distributor, you could buy a gang programmer or use the sockets in my link above to program them yourself before attaching them.
If you are doing ict you can do it as part of the test on the end of the line. For high volume reprogramming I've even seen people make little programming devices you can just plug into your board hit a button and let it reprogram. The list goes on and on, just depends how you want to handle it.
This shouldn't be too hard with a little planning.
I cannot actually find any logical errors in your procedure, but here are some suggestions:
there's also a FTMRH_FERSTAT register (at 4002_0007h). It's supposed to tell you what went wrong... but only in the case of parity (or double parity errors). I'm not convinced this will record anything in case or erase errors, but probably worth checking out.
the KEA documentation also mentions that an interrupt may be triggered by flash errors (section "18.3.5 Flash and EEPROM interrupts"). I don't know if that's what happens when the SEGGER erases it, but it is a plausible explanation as to why the PC changes too since you did see errors flagged in the FSTAT register. Unfortunately the KEA documentation section for the interrupt controller ("3.3.2 Nested Vectored Interrupt Controller (NVIC) configuration") is rather vaguely pointing in the direction of ARM's website for full documentation. I wasn't able to figure out if there is a default interrupt handler set up (at boot) for flash errors.
You've only done erases at sector level manually, so try to manually (as in by writing the appropriate register yourself) issue a full flash erase command; the only way to do this in a single command seems to be the "Unsecure flash command" documented in section 18.3.9.10 (p. 246) of the manual. This will both "unsecure" the device and do a full flash and EEPROM erase. You can poll a FSTAT bit (CCIF) to see when it's supposedly completed and check the error flags again afterwards. EDIT: there's also a "18.3.9.7 Erase All Blocks command" section in the manual, duh.
try a lower bus clock frequency. Anything above 0.8 Mhz works according to the documentation. I'm suggesting this because there was one thread on the Freescale forum where an external flash worked fine, but not above a certain frequency that still was in the ok-documented range. So it's possible that the flash controller in the chip is flakey and cannot operate on the full range of stated frequencies.
likewise, thy a different chip. It's not inconceivable that given how much these cost (around $3) you've got a bad one. I do remember having an embedded x86 chip that worked fine in most ways but had weird errors on certain protected mode instructions; my problem went away with a different device of the same make. It's not clear to me if Freescale has (publicly stated) steppings and errata for these devices or not.
This is all I can think of in terms of debugging suggestions that wasn't said by others on this page.
20150103 edit(s):
(Moved material here from my comments & expanded)
It seems that not all Kinetis Series are (officially, at least) tested with all flashers. The fairly new EA series that you're actually using appears to be officially supported only by Freescale's own/OEM Cyclone MAX flasher; it's the only one listed on Freescale's page for the EA serires. Now granted, for older Kinetis like KL0 the list is much longer, including a SEGGER. I don't know if that's simply because of a lack of testing of other flashers for the EA series or if there's actually some programming quirk involved that only their Cyclone MAX currently knows about. I was hoping that maybe this is just Freescale being slow on listing other flashers, but upon checking the J-link manual (hopefully the right one), there's no Kinetis E or EA series listed there (p. 249) as tested either, but only Kinetis K10 to K60 devices (and some older MAC7's).
Worth noting is that the PExDrv software/firmware for the Cyclone MAX has a service pack (v10.3) dated 3/20/2014, which "Adds support for MKE04Z64, MKE04Z128, MKE06Z64, MKE06Z128, SKEAZ64 and SKEAZ128 derivatives." Another clue is that Freescale's own open-source bootloader/flashloader software for the Kinetis, despite being updated even more recently in 12/2014, does not list any E or EA [sub]series devices as supported. So I think there's something sufficiently different regarding flashing between the E/EA-series and other Kinetis like the K10, although I have no idea what exactly is that difference. Therefore I think that expecting EA flashing to work automatically with anything but the Cyclone MAX is probably unrealistic at this point. You might be able to eventually figure out how to do it at "bare metal" level (direct register commands) from the EA-series documentation, but I agree that the documentation is pretty obtuse; it certainly lacks any step-by-step instructions being just a reference manual. Had Freescale's open-source bootloader/flashloader supported the E/EA series, you'd have been able to peek at its source code and reproduce its steps... but that's alas not an option.
Your experiment with the FRDM-KL25Z (which comes with a Kinetis L series) points in the same direction, i.e. you can't swap an L-series with an EA-series and use the same flasher (OpenSDA in this case).
And if you're like Keith (the blogger) who "think[s] $100 dollars for a programmer is ridiculous", you probably won't be pleased with the perspective of dropping $900+ on that Cyclone. I don't know if Freescale does this on purpose to fleece their automotive customers or what... It surely looks odd that the tooling for most of the Kinetis series doesn't work with the E/EA.
Also beware that OpenSDA's flashing function only works under MS Windows, apparently.
If you're willing to try (hacking) more boards, one with an E-series Kinetis might a better idea, e.g. FRDM-KE02Z ($13 at Digi-Key); also uses OpenSDA so it might be hackable. They don't make/sell boards with the EA-series, as far as I can tell. However, it seems you cannot use one OpenSDA processor/board to program a different Kinetis type than the one on its own board, even if both processors are in the same (e.g. L) series, but different numbers. Unfortunately "Open" in OpenSDA only means the SDA spec is open, not that they give out the source code as open-source; so I can't even find source code to program an E-series flash. Apparently, I'm only half-right about that. OpenSDA v1 is not open-source, but v2 is.
So here's the lowdown on OpenSDAv2. It's basically just a CMSIS-DAP/mbed bootloader & flasher. So it may not have the same features or support the same chips as v1... and that actually turns out to be the case because flash_features.h does not list any MKE (Kinetis E-series) let alone SKE (EA-series) devices. In summary, Freescale's proposition for the EA series seem to be: buy our $900 Cyclone flasher or good luck writing your own from whatever incomplete bits of open source we have released.
It turns out however that there is an open source project that can program at least the E-series Kinetis, namely USBDM. The relevant bit from its changelog is:
V4.1.6.140 (April 2014)
Additional Kinetis devices (MKE04, MKE06, MK64F)
- Fixes for MKE devices (failed to program except after Mass Erase)
And based on that log entry, it surely appears the E-series are quirky. There's no direct support for EA-series (SKE), but that code base is probably your best bet if you want to hack your own flasher; or perhaps you can convince USBDM's author to add EA-series (SKE) support. As hardware for USBDM it turns out you can use the FRDM-KL25Z you've alreadly acquired; but you still have to hack the USBDM software to support the SKE chips.
The master config file for USBDM looks rather daunting. In USDBM different flashers (code bases) are used for different MKE series devices: something called "FTMRE" is used for MKE04 & MKE06, but "FTMRH" is used for MKE02. After looking myself briefly at the two code bases, you almost surely want the FTRMH code base not the FTRME one. The latter has a different FTMRH structure than your SKEA64 device, for example, the clock divider is not the first but the 4th field. FTRME also sets the bus FIDV to 0x17 = 24Mhz, which seems out of range for your chip (p. 224 in the KEA64 manual suggests max 20Mhz). FTMRH sets it to 0x0F = 16Mhz (like you do), which seems okay.
At this point, (unless you wanna buy the Cyclone MAX) your best bet is to contact Podonoghue to get your chip working with his code base. He seems active and quite willing to help with new devices (on the freescale forum).
Also from that USDBM source code I can prophesy that there's no way your SEGGER can correctly flash your SKEA by itself unless it gets its own firmware update first. Why do I say that? Because USDBM's FTMRH code base is used by exactly one device there, the MKE02, which your SEGGER seems to know nothing about either (based on its manual). Other, more common devices like the Kinetis L and K series use a different USDBM flasher based on a "FTFA" code base. If you look at FTFA's code, the flash controller register structure (also starting at 0x40020000) is different for these; the first field isn't even a clock divider, but the stat register, etc. "Great" way for Freescale to make incompatible devices... but a boon for flasher-makers, no doubt.
Best Answer
I know nothing about the K8x specifically, but you have a general conceptual problem: You have two entities competing for access to the QSPI interface, the instruction decoder and the filesystem code.
If you could guarantee that they never need access simultaneously, there would be no problem, but the fact is that the instruction decoder can require an XIP fetch at any time, even when using cache. If that demand occurs during a filesystem access, the system will lock up.
Changing settings or changing the external flash module will not help. The bottleneck is the QSPI controller itself.
As Chris suggested, the fix is to make sure that all of the code required to complete any filesystem access is NOT executing directly from the external flash module. Instead, copy the filesystem driver and anything that it depends on into internal flash or RAM (or external DDR SDRAM).