Re: [avr-chat] Can avrdude-5.3.1 handle stk500v1 and ATtiny15?

[Erik Christiansen]

On Thu, Mar 08, 2007 at 07:16:19AM +0100, Joerg Wunsch wrote:
> 
> Ick.  Please replace buf[pagesize + 16] in the beginning of that
> function by buf[256 + 16] (256 is the maximal page size of an AVR), as
> a stop-gap measure.  pagesize is initially 0 when we enter the
> function, so we allocate 16 bytes only.  Then we notice it's 0, and
> invent an artifitial 128 bytes pagesize.  Obviously, now the buffer's
> way too small for the data to fit.

I tried it two ways:

A) With this in stk500.c:

>>>
static int stk500_paged_write(PROGRAMMER * pgm, AVRPART * p, AVRMEM * m,
                              int page_size, int n_bytes)
{
//unsigned char buf[page_size + 16];
  unsigned char buf[256 + 16];
<<<

and no PAGEL or BS in avrdude.conf, the crash cause now changes to a
floating point exception:

avrdude: 126 bytes of flash written
avrdude: verifying flash memory against obj/flash.srec:
avrdude: load data flash data from input file obj/flash.srec:
avrdude: input file obj/flash.srec auto detected as Motorola S-Record
avrdude: input file obj/flash.srec contains 126 bytes
avrdude: reading on-chip flash data:

Reading |                                                    | 0% 0.00s
Program received signal SIGFPE, Arithmetic exception.
0x08060f63 in stk500_paged_load (pgm=0x8089b18, p=0x81bec20, m=0x81c0048, 
    page_size=0, n_bytes=Variable "n_bytes" is not available.
) at stk500.c:833
833         if ((n_bytes % page_size) != 0) {


B) Also adding these ATtiny15 values to /usr/local/etc/avrdude.conf:


    pagel               = 1;
    bs2                 = 1;

The behaviour then changes to:

$ avrdude -c stk500v1 -p t15 -e -U flash:w:obj/flash.srec

avrdude: stk500_recv(): programmer is not responding

(Trying pagel = 0xd7; does the same.)

> I think the actual error is that the paged write function should not
> be called at all, but I have to think a bit about that.

It's no problem if this goes on the back burner. :-)
I can just upgrade my firmware, if v2 is known to work.

The fuse programming enhancement that you and Eric are planning looks
much more rewarding. (I'm just sorry I don't currently have enough spare
headspace to devote to what looks like a fine solution.)

Cheers,
Erik