On Friday 18 December 2009, Michael Schwingen wrote: > David Brownell wrote: > > Never attempt to write partial words. The hardware only > > allows writing entire words ... so don't guess about what > > users want to do with the other bytes. Require them to > > say explicitly what data they want written. > > Hm. Not sure if this patch affects "write binary" behaviour, but in the > past, I had problems writing binary files with an odd number of bytes to > flash, because the last byte would trigger a similar check.
Last byte? Sounds like a different issue. Maybe related; were you talking to 16-bit wide NOR at the time? If so, you counldn't see such problems except with a single byte at the end. :) I'm a bit concerned because this behavior looks troublesome, but it's seemingly been there long enough for things to start depending on that dubious behavior. (Hence the "RFC" in $SUBJECT!) > If this patch re-introduces that behaviour, I ask not to apply it - it > would make writing programs with odd-sized data segments a pain. I might want to stick in a warning; ISTR that linker scripts can be taught not to create such segments, and thus to avoid such behaviors (and warnings). Though ... I suppose that just verifying flash writes would catch a number of these problems too. After all, the main constraint is that zero bits can't turn back to ones... Semi-related ... how about the generic NOR patch insisting that erases only apply to whole sectors? It's not quite the converse of this patch. This one was perhaps more on the side of paranoia. That one was concern that the code was certainly doing something destructive, by clobbering data it was told to leave alone. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
