(Better subscribe to the list to not miss replies.) Mike Meyer <[email protected]> wrote:
> Is there some reason that avrdude doesn't do any requested write > operations before doing the erase for the flash? Or is it just that > nobody has asked for it yet? It's more a matter that nobody *implemented* it. Right now, AVRDUDE first passes the entire commandline arguments. It then goes ahead, and analyzes all -U options to see whether there's one that would want to write to "flash" (or in the SVN version, for Xmega parts, to "application"). If so, and if auto-erase is not forbidden, it then erases the part. Likewise, if there's a -e option around anywhere on the commandline, it also issues an erase cycle. Only then, it starts processing the -U (update) options. And no, that's not so easy to avoid as you might think. For non-Xmega devices, the erase operation is performed as a chip erase, which can potentially also erase the EEPROM. Suppose we would generally defer that operation until the actual flash write -U option is being processed, it could then lead to a previously performed EEPROM write to be clobbered. The only chance I'd see to avoid further side effects would be to add another -U suboption "e" (for "erase"). As all -U options are processed in order, this would specify the exact timing of when the erase happens. (Presence of at least one -U ...:e: option could then be used as an indication to not schedule the default auto-erase before processing the -U options.) This would have the added bonus that it also easily solves the missing feature where we are currently not able to specify an erase operation for individual Xmega flash regions (boot vs. application). So perhaps I'm going to implement it that way before releasing version 6.0. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-chat mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/avr-chat
