optiboot (Arduino UNO)- protocol error in stk500_set_extended_parms()

[hagaigold]

avrdude sends a different message based on the optiboot version, in avrdude/src/stk500.c:

  // MIB510 does not need extparams
  if (strcmp(ldata(lfirst(pgm->id)), "mib510") == 0)
    n_extparms = 0;
  else if ((maj > 1) || ((maj == 1) && (min > 10)))
    n_extparms = 4;
  else
    n_extparms = 3;

so, when the version of this bootloader crossed 1.10:

        if(which == 0x82)
        {
            // Send tftpboot version as "minor SW version"
            putch(BUILD_MINOR_VER);
        }
        else if(which == 0x81)
        {
            putch(BUILD_MAJOR_VER);
        }

the below error kicked in: (Firmware Version 11.3 > 1.10)

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : COM7
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
         AVR Part                      : ATmega328P
. . .
. . .
         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 3
         Firmware Version: 11.3
         Vtarget         : 0.3 V
         Varef           : 0.3 V
         Oscillator      : 28.800 kHz
         SCK period      : 3.3 us

avrdude: stk500_set_extended_parms(): protocol error, expect=0x14, resp=0x0d
avrdude: stk500_initialize(): failed
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x0a

avrdude done.  Thank you.

the selected serial port 
 does not exist or your board is not connected

[hagaigold]

@phillipjohnston, not directly related to that issue but still, I wonder why the version jumped from 1.x.x to 11.x.x?

[phillipjohnston]

Uh, I think that was just a mistake somewhere along the line, going through the history I don't really see a good reason.

[phillipjohnston]

So it seems that for Optiboot, we should not be referencing the Athena version number, but rather the version of Optiboot we derived from. And that number should be < 1.10 because the > 1.10 behavior is what is breaking things.

Do you agree? Or am I misinterpreting the problem?

[phillipjohnston]

And then the question is whether or not it will be a problem for people if we go back from v11 to v1.

[hagaigold]

So it seems that for Optiboot, we should not be referencing the Athena version number, but rather the version of Optiboot we derived from. And that number should be < 1.10 because the > 1.10 behavior is what is breaking things.

Do you agree? Or am I misinterpreting the problem?

I tried to go backward to find the Optiboot version we derived from, but couldn't find where the following code came from:

    else if(ch == STK_SET_DEVICE_EXT)
    {
        // SET DEVICE EXT is ignored
        getNch(4);
    }

so I fixed it for both options: <= 1.10 & > 1.10. maybe down the road, someone will fork and change the version for his like???

anyway, regarding the version we referencing- I think this should be ok now

[hagaigold]

And then the question is whether or not it will be a problem for people if we go back from v11 to v1.

I was just curious about the 11 number if it had some meaning with/for the build system. I wouldn't go back for the reason you mentioned.