Re: [avrdude-dev] [bug #43471] avrdude 5.11 buffer overruns in stk500v2 code

[Bob Frazier]

On 11/19/14 09:06, Joerg Wunsch so wittily quipped:
> The problem is that this situation (Xmega but STK500v2 protocol 
> anyway) is uncommon.  The entire code had been tailored on the 
> non-Xmega devices as Xmegas use their own (different) protocols.

I'm using 'wiring' to be compatible with Arduino's IDE.  'Wiring' uses
STK500v2, and relies on the avrdude implementation to simply 'send the
hex file'.  It's the same as the mega2560 except that it uses 512 byte
flash blocks instead of 256, and that's where the problem shows up.

> I think the actual issue is that the following procedure 
> described in AVR068 is not implemented:
> 
> "For devices with page size bigger than what can be 
> transferred to STK500 in one command, several 
> CMD_PROGRAM_FLASH_ISP commands must be issued.  In such a 
> case, only the last command should have the Write Page mode 
> bit set."
> 
> I wonder whether your bootloader would be able to handle that.

I set it up to allow writing partial blocks [if the protocol made "that"
happen I'd be able to test it], even though you have to
'read-modify-write' the flash page.  So flashing would 'wiggle' the bits
multiple times per file, reducing the flash capacity of the device by
'more than one' for each flash you do.  For 512 byte pages it would
potentially be 2 times per flash.  For larger pages, an appropriately
larger number.

> Nevertheless, changing the fixed buffers into malloc'ed 
> buffers might make a lot of sense.  Other programmer 
> implementations (like those for the JTAGICEs) already do it 
> that way.

yes - better programming practices for sure.  fixed-length buffers on
the stack are the source of *SO* many problems.