Re: [avrdude-dev] stk500 and firmware 1.14

[Theodore A. Roth]

On Wed, 19 Feb 2003, Brian Dean wrote:

:) On Wed, Feb 19, 2003 at 10:54:48AM -0800, Theodore A. Roth wrote:
:)
:) > Have a look at the "Parallel Programming Parameters, Pin Mapping, and
:) > Commands" section in the m128 datasheed (page 286 in my version).
:) > Those signals are used for h-v parallel programming. Not needed for
:) > spi programming, but the stk500 still needs to set them up for devices
:) > that don't have spi programming interfaces.
:)
:) Ah, I see.  These are undoubtedly per-chip settings - I guess we'll
:) want to extend the config file parser so that we can tell avrdude
:) about them.

Yep.

:)
:) What was the fourth byte to "set extended device" that was added
:) recently?

>From my latest hack to uisp:

/* Set the Extened Device Programming parameters. In the future, this may
   require more than 3 arguments. */

struct SPrgExtDevParams {
  const TByte eepgsz;           // EEPROM page size in bytes.
  const TByte sig_pagel;        // Defines which port pin the PAGEL signal
                                // should be mapped on to. e.g. 0xD7 maps to
                                // PORTD7.
  const TByte sig_bs2;          // Defines which port pin the BS2 signal
                                // should be mapped on to.
  const TByte reset_disable;    // Req'd by firmware version 1.14.  It's a
                                // flag which tells whether a device uses the
                                // reset pin as an IO pin. Where 0x00 =
                                // Dedicated RESET pin, 0x01 = Can't rely on
                                // RESET pin for going into programming
                                // mode. Not needed for SPI programming
                                // though.
};


:)
:) Also, just curious, if a device supports both programming modes,
:) serial and parallel, how does the stk500 decide which to use?  I don't
:) see anything that jumps out at me that you tell to stk500 to
:) explicitly use one or the other.  Are there jumpers on the board that
:) set the programming mode maybe?

>From what I can tell from this snippet of a patch for uisp:

@@ -496,14 +671,20 @@
   memcpy(buf, pSTK500, sizeof(pSTK500));
   Send(buf, sizeof(pSTK500), sizeof(pSTK500_Reply));
   if (memcmp(buf, pSTK500_Reply, sizeof(pSTK500_Reply)) != 0) {
-    throw Error_Device ("Device is not responding correctly."); }
+    throw Error_Device ("[4] Device is not responding correctly."); }

   memcpy(buf, &prg_part[desired_part].params,
      sizeof(prg_part[desired_part].params));
+
+  /* switch to parallel mode if selected via -mode=p */
+  if(mode=='p') {
+      buf[3]=0x01;
+  }
+
   Send(buf, sizeof(prg_part[desired_part].params),
        sizeof(DeviceParam_Reply));
   if (memcmp(buf, DeviceParam_Reply, sizeof(DeviceParam_Reply)) != 0)
{
-    throw Error_Device ("Device is not responding correctly."); }
+    throw Error_Device ("[5] Device is not responding correctly."); }

   memcpy(buf, SWminor, sizeof(SWminor));
   Send(buf, sizeof(SWminor), sizeof(SWminor_Reply));


the stk500 will use serial mode if the byte is 0 or use parallel mode
if the third byte of the dev params is 1. Basically you can force
parallel mode for any device by setting that byte to 1.

This code in avrdude (stk500.c):

    434   buf[1] = p->devicecode;
    435   buf[2] = 0; /* device revision */
    436   buf[3] = 0; /* parallel and serial programming */
    437   buf[4] = 1; /* full parallel interface */
    438   buf[5] = 1; /* polling supported - XXX need this in config file */
    439   buf[6] = 1; /* programming is self-timed - XXX need in config file */

shows me that you will always be using serial mode. There should be a
way to set byte 3 to 1 to use parallel mode.

Ted