On Thursday 24 December 2009, David Brownell wrote: > + > + /* REVISIT This needlessly touches sectors BETWEEN the > + * sections it's writing. Without auto erase, it just > + * writes ones; unlikely to destroy data.
For the record, some more information has come up ... there are cases where this CAN (or even WILL) destroy data. For now I'll just update that comment. Sorry for the nasty forum URLs here: http://www.luminarymicro.com/component/option,com_joomlaboard/Itemid,92/func,view/id,7594/catid,5/limit,6/limitstart,6/ http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&thread.id=8282 The "clean" failure is with Stellaris Tempest flash, which keeps ECC data for each word. Sufficient for correcting single bit errors? ECC for all-ones != ECC for other data. So assuming the data write checks out ... the wrong ECC is going to be written. If that succeeds even in part (one bit changing), that data won't read correctly any more. The "dirty" failure is with some FreeScale parts; there's a URL for an HC11 manual with about ten pages of discussion on the issue, where issues like odd transistor biases leading to "soft" programming come up. And yes, implicit recognition that many folk seem to think writing ones should be OK, because often that's been true. So it looks like the NOR load-image code should get fixed to not write those data, even as all-ones. > + * > + * With auto erase enabled, data in those sectors will > + * be needlessly destroyed; and some of the limited > + * number of flash erase cycles will be wasted. > + * > + * In both cases, the extra writes slow things down. > + */ _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
