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

[Jan-Hinnerk Reichert]

On Wednesday 25 February 2004 01:22, Klaus Rudolph wrote:
> Jan-Hinnerk Reichert wrote:
> > Hi Klaus,
> >
> > avrdude only supports SPI-programming.
> >
> > According to the datasheet the AT90S1200 has only a SPI-command
> > for setting lock-bits. All other operations on lock- or fuse-bits
> > are not supported.
> >
> > The only bug seems to be that the config-file defines commands
> > for these actions. Either they are from an outdated datasheet or
> > (more likely) copied from another chip definition.
>
> Seems to be a much bigger problem here...
>
> As I looked a bit inside the code the fuse bits will be read out
> with the
> universal command what is not possible with actual firmware I
> think. Instead the commands 0x72 (ReadFuseBit) 0x77
> (ReadFuseBitsExt) and 0x73 (ReasdLockBits)
> should be used.

I agree that it is not the best way to handle things (and it will not 
work in parallel mode).

However, I can't see why this should fail on newer firmware unless the 
universal command has been removed.

> I have changed the SPI to parallel programming in the setup, but
> this is not enough.

Of course, the universal command won't work in parallel mode ;-(

> As I think after 2 hour of code inspection there is a
> avr_read_byte_default function which
> uses for stk500 the stk500_cmd function which is not correct for
> fuses I think.

Yes, that's the way it works.

> Also for at90s1200
> the function readLockBits (0x73) must be used to read fuse bits.
> (This info comes from tracing
> avr-studio and reading the AVR061 document).

Well, it would not be too hard to change the code to use the 
appropriate functions.

However, I don't know how the parameters to these functions are 
interpreted. It would be very bad, if the same value would result 
different fuse-settings depending on the programming mode.

Do you know of any documentation?
Is the STK500-source available somewhere?

> Additional an other error was found. The command 0x45 needs 4 bytes
> info and not 5! The code
> holds an n_params+1 line. Thats not correct as I look inside the
> avrstudio trace for that.
> Currently it doesn´t matter but for future firmware?

I think you are right.

Cheers
  Jan-Hinnerk