It doesn't handle the situation where the checksum of a received command is incorrect. In that situation, it's supposed to respond with an ANSWER_CKSUM_ERROR answer. Instead, if my interpretation of the code is correct, what it would do instead is ignore the entire command and simply wait to receive the next one. The sending application would be none the wiser that anything was wrong, and just keep on truckin'.
Upon a second reading, I realise I had indeed mis-interpreted this code.
It's not quite as bad as I feared (silently ignoring commands), but still wrong. In the case of a bad checksum, yes it will ignore that command and wait for the next, but I realise now that because this will not result in an answer being given to the bad command, it will cause the programming application to time out, and presumably abort the programming process with an error. So, the user will be misled as to the cause of the programming error, and also any retry mechanism in the programming app will be precluded.
You just move a little chunk of code, and change an 'if' to a 'while'
Thanks for that. A good base for if I decide to implement chip erase. I would probably change it so it erases from last to first page, just to be safer. Also, to be complete, as a chip erase is also supposed to encompass an EEPROM erasure (but only to be performed if the EESAVE fuse is not set), that would need adding too.