David Brownell wrote: >> 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. :) > No, IIRC it was when flashing the internal flash on a LM3S6918 - the error happened on the last byte, since the length of the last segment was not padded to a word boundary. > 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). > Yes, however, when flashing readily-downloaded sample binaries this can get troublesome. A warning is OK with me.
> 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... > Sounds good. Another alternative would be to read the current flash contents, patch in the byte to be written, and then write it back. That way, a single byte at the end of a segment can be written, and nothing is accidentally overwritten. > 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. > Allowing erase only on complete sectors is fine with me, because the damage potential is large, and I see no direct use case where you would specify a partial sector and expect that the whole sector should be erased. One thing to take care of would be write_image with the erase option: the image will probably not competely fill the last sector, but the erase should not fail in that case. cu Michael _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
