Re: [avrdude-dev] Problems reading writing fuses to at90s1200 with stk500

[Theodore A. Roth]

On Thu, 26 Feb 2004, Brian Dean wrote:

> On Wed, Feb 25, 2004 at 08:36:42PM +0100, Klaus Rudolph wrote:
>
> > Jan-Hinnerk Reichert wrote:
> >
> > > Are you sure that newer firmware also uses 0x7x commands in serial
> > > mode?
> >
> > I?m shure that the new firmware use in serial mode also the universal
> > command.
> > So nothing must changed here :-)))
>
> What exactly is required to make the STK500 use parallel programming
> mode instead of serial programming mode?  Does it use it automatically
> if it detects a chip in the socket, and the chip supports parallel
> programming mode?  I could be missing it, but I don't see an explicit
> command or parameter that says to use parallel mode over serial.  I
> only see the case where parameters are passed (command 0x42) that
> indicate which programming modes are supported, and command 0x45 that
> indicates some additional parallel programming signals, but not
> anything that says for it to use programming mode.

To put the stk500 into parallel programming mode should only require
change this code to allow the user to override the config file and set
this param to 1:

[from stk500.c]
370   if ((p->flags & AVRPART_SERIALOK) && (p->flags & AVRPART_PARALLELOK))
371     buf[3] = 0; /* device supports parallel and serial programming */
372   else
373     buf[3] = 1; /* device supports parallel only */

If the user selects parallel mode, then the stk500 code should swap in
the parallel versions of the fuse and lock bit methods. Also, if the
device is parallel programming only (for fuses and lock bits), those
methods must be swapped in by default regardless of what the user says
on the command line.

This functionality is something I've wanted to add for a long but
haven't had the chance. It's really needed if you hose the fuses such
that the device can't get a osc signal or you accidently disable both
jtag and spi programming. I've never done either of those (*cough*).

>
> > So the parallel mode is "only" a complete add on without any other
> > change.
> >
> > For my opinion it is quite simple to copy the stk500.c to stk500p.c
> > and start there.  The selection must be done at startup from command
> > line with an other programmer selection like "avrdude -c stk500p
> > ..."  All needed things should be walk like say ever walk. After all
> > changes done and tested through all users a time the stk500 could
> > diff agains stk500p and the serial part of stk500.c move to
> > stk500s.c, the generic part stay at stk500.c and the parallel things
> > handled in stk500p.c
>
> It seems overkill to copy the code and have two STK500 support files,
> one that uses universal command for fuse bytes, and the other that
> uses STK500 specific commands.
>
> Why not instead introduce new programmer entry points for
> reading/writing fuse bytes.  These would be initialized to the
> existing "universal command" method by default.
>
> It shouldn't be too hard to make the 'open' or 'initialize' routine
> query the firmware, and change the default entry points for the fuse
> reading/writing functions to be its own (better) replacements than the
> defaults, based on the firmware revision.  Each programmer could do
> this if desired, not just the STK500.  Or if a programmer does
> nothing, they just get the default which would operate as it does
> today.  We already do this for some other memory programming, i.e., if
> the specific programmer has a more efficient method for programming
> the flash, it's own supplied routine is used instead of the more
> generic default routine.

I don't think you can problem the hardware to know if you have the
stk500 wired up for Hi-V programming.

Ted Roth